Inline snapshots store the expected value directly inside your test file instead of a separate .snap file. This lesson covers toMatchInlineSnapshot() and when it's more convenient than the standard approach.
toMatchInlineSnapshot()
expect(value).toMatchInlineSnapshot() works like toMatchSnapshot(), but instead of saving to a __snapshots__ folder, Jest automatically writes the serialized value as a string argument directly into your test source code, right where the call is made.
This keeps the expected value visible right next to the test, which is convenient for small, quick assertions where flipping between two files feels unnecessary.
test('formats a name', () => {
expect(formatName('ada', 'lovelace')).toMatchInlineSnapshot();
});
// After running once, Jest rewrites the file to:
test('formats a name', () => {
expect(formatName('ada', 'lovelace')).toMatchInlineSnapshot(`"Ada Lovelace"`);
});
Jest edits the test file itself to insert the snapshot value as a string literal argument.
Updating Inline Snapshots
npx jest -u // updates both inline and file-based snapshots
The same -u (or --updateSnapshot) flag updates inline snapshots too.
Because Jest rewrites your source file, your editor/IDE should have the file closed or configured to reload from disk.
Inline snapshots require Prettier to be installed for automatic formatting of the inserted value.
Best suited to small, single-value snapshots; large ones bloat the test file itself.
Inline Snapshots Cheat Sheet
How inline snapshots compare to standard file-based snapshots.
Aspect
toMatchSnapshot()
toMatchInlineSnapshot()
Storage
Separate .snap file
Directly in the test file
Best for
Large/complex output
Small, simple values
Requires Prettier
No
Yes, for formatting
Update command
jest -u
jest -u
Review location
Separate file diff
Inline in the same diff
Why Choose Inline Over File-Based Snapshots
Inline snapshots keep small expected values visible directly in the test, which some teams find easier to review in pull requests since there's no need to open a second .snap file to see what changed. They work best for short strings or small objects, not full component trees.
For large component trees or big objects, an inline snapshot makes the test file itself hard to read, since a huge serialized string gets embedded directly in your source. In those cases, the standard file-based .toMatchSnapshot() keeps your test logic separate from the (large) expected output.
Common Mistakes
Using inline snapshots for large objects or component trees, bloating the test file.
Forgetting Prettier is required for Jest to format inline snapshot values correctly.
Editing an editor buffer while Jest rewrites the same file with -u, causing conflicting changes.
Not reviewing an inline snapshot diff carefully just because it looks like a small change.
Key Takeaways
toMatchInlineSnapshot() writes the snapshot value directly into your test source file.
It's best suited for small, simple values rather than large structured output.
The same -u flag updates inline snapshots, just like file-based ones.
Prettier must be installed for Jest to format the inserted snapshot value.
Pro Tip
Reserve inline snapshots for short, simple values like formatted strings. For anything resembling a full object or component tree, stick with standard .toMatchSnapshot() to keep your test files readable.
You now know when to use inline snapshots. Next, learn the workflow for updating snapshots safely as your code changes.