Skip to content

Jest Inline Snapshots

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.

test('pluralizes correctly', () => {
  expect(pluralize('cat', 1)).toMatchInlineSnapshot(`"1 cat"`);
  expect(pluralize('cat', 3)).toMatchInlineSnapshot(`"3 cats"`);
});

When to Avoid Inline Snapshots

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.