Cypress end-to-end test isolation starts each test in a clean browser context by default, so tests are less likely to depend on what ran before them. Keep testIsolation enabled for independent tests, use cy.session() to reuse login state, and disable isolation only for a deliberately scoped suite whose tests you have verified can also pass alone.
Why Cypress test isolation matters
A test that passes only after another test has run is order-dependent: its result relies on hidden state left behind by earlier work. That makes failures harder to reproduce and diagnose. Cypress’s guidance is that tests should pass independently as well as consecutively with other tests (Cypress: Test Isolation).
Isolation gives each end-to-end test a predictable starting point. It does not guarantee that every external dependency is deterministic, but it prevents many failures caused by leftover page and browser state.
What Cypress resets between end-to-end tests
With testIsolation: true, Cypress visits about:blank and clears cookies, localStorage, and sessionStorage across all domains before each test. It also resets Cypress test state, including aliases, clock mocks, intercepts, spies, stubs, and viewport changes.
Free tools Windows power users keep installed
One-click scans. No signup required.
This is not a wipe of every browser storage mechanism. IndexedDB and other browser storage mechanisms are not cleared by test isolation. If your application uses them, arrange cleanup or deterministic setup in your tests rather than assuming the next test starts without that data.
Configure isolation for end-to-end tests
Keep the default enabled for independent tests
Test isolation is enabled by default for end-to-end testing. You can make the setting explicit in your Cypress configuration:
import { defineConfig } from 'cypress';
export default defineConfig({
e2e: {
testIsolation: true,
},
});This configuration belongs in the project’s Cypress configuration file. If your project uses a different configuration format, set the same e2e.testIsolation option there.
Scope disabled isolation to a suite when necessary
If a particular end-to-end suite needs the page and browser context to persist between tests, override the setting on its describe or context block instead of changing project-wide behavior:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsdescribe('a suite that intentionally shares browser state', { testIsolation: false }, () => {
it('does one part of the workflow', () => {
// Test steps
});
it('does another part of the workflow', () => {
// Test steps
});
});With isolation disabled, Cypress does not alter the browser context before each test, so the page, cookies, and storage can remain available. The trade-off is that tests can become dependent on execution order. Before relying on this setting, run each test by itself with .only() and confirm it still passes.
Reuse login state with cy.session()
When a test needs an authenticated browser, cy.session() can capture and restore the cookies and local or session storage present after its setup. Cypress recommends putting session setup in a reusable login command or wrapper rather than duplicating it across spec files.
For example, a reusable command can establish a session and then visit the application page in the test:
Cypress.Commands.add('login', (username, password) => {
cy.session([username], () => {
cy.visit('/login');
cy.get('[name="username"]').type(username);
cy.get('[name="password"]').type(password);
cy.get('button[type="submit"]').click();
});
});
describe('account page', () => {
it('shows the signed-in account', () => {
cy.login('test-user', 'test-password');
cy.visit('/account');
cy.contains('Account').should('be.visible');
});
});Adapt selectors and the login flow to your application. With test isolation enabled, the page is cleared when session setup or restoration occurs; the session restores browser storage, not the page under test. Call cy.visit() after the session call to load the application. Session data is cleared before the setup callback runs regardless of the isolation configuration (Cypress: cy.session()).
Choose between isolation, shared state, and session caching
| Approach | Page and DOM between tests | Cookies and web storage | Setup and order-dependency considerations |
|---|---|---|---|
testIsolation: true |
Page is cleared by visiting about:blank. |
Cookies, localStorage, and sessionStorage are cleared across domains. | Tests start independently; visit the application and establish required state for each test, or restore a session. |
testIsolation: false |
Browser context is not reset before each test; the page can persist. | Cookies and storage can persist. | May avoid repeated setup, but risks state leakage and order-dependent tests. Check each test alone before relying on it. |
cy.session() with isolation enabled |
Page is cleared; visit the application after session restoration. | Cookies and local/session storage from session setup can be restored. | Provides reusable login state without making the page itself persist between tests. |
Component testing has different reset behavior
Cypress component testing unmounts the rendered component and clears cookies, localStorage, and sessionStorage before each test. Cypress does not expose the same configurable testIsolation option for component tests. Do not apply end-to-end configuration examples as if they changed component-test isolation (Cypress: Test Isolation).
Rank #4
Migration note for Cypress 12
Cypress 12 introduced enforcement of a clean browser context for tests. If a suite migrated from an earlier setup and expected the application page to remain open between tests, revisit the app and rebuild any required browser state in each test or use cy.session() for reusable authentication. The migration guidance describes testIsolation: true and false in that Cypress 12 context; check the current Cypress documentation when upgrading a project (Cypress 12 migration guide).
Troubleshoot isolation problems
- A test works in the full suite but fails alone: it may depend on state created by another test. Establish its own prerequisites, or use a session for authentication rather than relying on a previous test’s login.
- A test is unexpectedly logged out after session setup: under isolation, the page is cleared while session data is established or restored. Visit the application after
cy.session(). - Data appears to survive between tests: isolation clears cookies and local/session storage, not IndexedDB or every browser storage mechanism. Add application-specific cleanup or setup for the storage your app uses.
- A page disappears between tests: that is expected with isolation enabled. Each test should visit the page it needs; if a specific suite intentionally shares the browser context, scope
testIsolation: falseto that suite and verify tests individually. - A component test ignores
testIsolation: component testing has fixed reset behavior and does not offer the same configurable option as end-to-end testing.
Performance and reliability trade-offs
Disabling isolation can improve end-to-end performance by avoiding some resets, but Cypress does not publish a quantified speed gain for this setting. Weigh any measured project-specific savings against the maintenance cost of order-dependent tests. Independent tests are generally easier to rerun and debug; session caching can reduce repeated login setup without preserving the whole page between tests.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Or skip the browser setup
ScreenshotNeo is a separate option for capturing a webpage as an image or PDF; it does not replace Cypress test isolation or run Cypress tests. Its API can return a screenshot with one GET request:
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Best Value
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpSee the ScreenshotNeo API documentation for request options. ScreenshotNeo accepts cookie or consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and the response indicates the page verdict and billing status. Its MCP server provides screenshot and PDF tools for AI agents. The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. See ScreenshotNeo for details, or sign up free for 1,000 screenshots a month with no card.
Frequently Asked Questions
Can I preserve browser state for just one Cypress suite?
Yes. Set testIsolation: false on that suite’s describe or context block rather than changing the project-wide end-to-end setting.
Does Cypress test isolation clear IndexedDB?
No. IndexedDB and other browser storage mechanisms are not cleared by test isolation; provide cleanup or deterministic setup for them.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →
