Playwright Save Cookies
To use playwright save cookies, you export the browser context storage state to a file. Your test runner then loads this file into new browser contexts to skip login steps. Teams use this workflow so automated tests do not log in before every single check. Still, saving active sessions with broad permissions creates a high risk if those files leak. Anyone who reads that storage file can act as that user inside your app. How playwright save cookies works in a test run Playwright runs tests ins
Save Cookies: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To use playwright save cookies, you export the browser context storage state to a file. Your test runner then loads this file into new browser contexts to skip login steps. Teams use this workflow so automated tests do not log in before every single check. Still, saving active sessions with broad permissions creates a high risk if those files leak. Anyone who reads that storage file can act as that user inside your app.
How playwright save cookies works in a test run
Playwright runs tests inside isolated browser contexts that act like fresh browser profiles. Each context holds its own cookies and local storage data during a test run. When you log in through the browser, the app sends back session cookies. Playwright lets you capture these cookies and local storage items in one setup step. The tool writes this session data into a local JSON file on your disk.
After the setup step finishes, later test steps read that saved file. Each new browser context starts with those cookies already loaded in memory. The web app sees the valid cookie and skips the login page right away. You can set up several files to test different user roles at the same time. For example, one file holds admin cookies while another holds viewer cookies.
Why teams store browser state for test suites
Logging in through a user interface takes several seconds for each test file. When a test suite has hundreds of checks, those login times add up fast. Reusing saved cookies cuts total run time and makes test suites much faster. It also stops your test runner from hitting rate limits on your login servers. Third-party login providers often block automated browsers that try to sign in too often.
Storing state in one setup step also keeps your test code clean. You only need to update one workflow if your login page changes its layout. All other tests just read the saved cookie file and start testing app features. Teams often run this setup once per test run on their build servers.
Save Cookies: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What saved browser state solves and what it leaves open
Saving cookies solves the speed problem for browser tests, but it creates security gaps. The saved JSON file holds raw session tokens in plain text on the machine. If a build server uploads test folders as shared build files, anyone can download them. If a developer stores this file in source control, the live session leaks to everyone. The native browser setup only checks who logs in at the start.
Once a test context loads a saved admin cookie, every request has full admin power. The browser state file cannot limit which commands or database queries run during the session. Also, test scripts often need direct database checks or backend commands alongside browser steps. Native cookie files do not track or control what those backend actions do in flight. They also do not mask sensitive data like emails or card numbers in test results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Where should teams store saved cookie files during tests?
Teams should write saved cookie files to a temporary folder on the test machine. You must add this folder to your ignore list so nobody commits it to git. Delete the files as soon as the test suite finishes its run.
Why do saved cookies stop working during long test runs?
Web apps set an expiration time on every session cookie they create. If your test suite runs longer than that limit, the app rejects the saved cookie. You must run the login setup step again to fetch a fresh cookie.
Can you share saved cookies across different browser types?
Yes, you can load the same saved state file into Chromium, Firefox, and WebKit. Standard cookies and local storage items follow the same format across all three browsers. You only need to run the login step once for all browser engines.