Playwright Storage State: Login Once, Reuse Session & Cookies

What Is Storage State?

When a user logs into an application, the browser stores authentication information.

Playwright captures this stored information as Storage State, allowing the same authenticated session to be reused later.

A simple analogy is logging into a website today and returning tomorrow without entering your username and password again because the browser has remembered your login.

Interview Answer

"Storage State in Playwright is used to save and reuse browser storage such as cookies, localStorage, and sessionStorage. It helps avoid repeated login by restoring an authenticated session. In real projects, Storage State is mainly used to improve execution speed and test stability."

Summary

Login Once and Reuse the Session

Logging into an application before every test increases execution time.

Playwright solves this by allowing authentication to be performed once and reused across all tests.

A simple analogy is visiting a website that remembers your login information, so you do not need to sign in every time.

Interview Answer

"In Playwright, we handle login once and reuse the session using Storage State. After successful authentication, we save the browser's storage into a JSON file and reuse it across all test cases. This avoids repeated login, reduces execution time, and improves test stability."

Workflow

• Perform login using either the UI or an API.
• Save the authenticated browser storage as a JSON file.
• Reuse the JSON file while creating new browser contexts.
• Every test starts with an already authenticated session.

Benefits

• Eliminates repeated login.
• Reduces execution time.
• Improves automation stability.
• Speeds up regression execution.

Storing Cookies and Local Storage

Cookies and Local Storage can be compared to an ID card issued by a website.

Once the browser receives this information, Playwright can save it for future use.

Storage Method

Playwright provides:

context.storageState()

to capture:

• Cookies
• Local Storage

The captured data is stored in a JSON file after successful authentication.

Later, this JSON file is reused while creating new browser contexts so that every browser session starts in an authenticated state.

Workflow

• Complete login.
• Save browser storage using storageState().
• Store the authentication data in a JSON file.
• Create new browser contexts using the saved storage state.
• Skip the login process in every subsequent test.

Real Project Usage

"In my project, we stored cookies and local storage immediately after login. Every subsequent test reused the saved session and skipped the login screen entirely."

Cookies vs Local Storage

Both Cookies and Local Storage store browser data, but they differ in their purpose and behavior.

Cookies

Cookies:

• Store a small amount of data.
• Have size limitations.
• Expire after a configured duration.
• Are automatically sent to the server with every request.
• Are primarily used for authentication.

Simple Analogy

Cookies are like a bus ticket.

Every time you board the bus, the conductor checks your ticket.

Similarly, cookies are automatically sent to the server with every request.

Local Storage

Local Storage:

• Stores larger amounts of client-side data.
• Does not expire automatically.
• Is not sent to the server.
• Remains available until manually cleared.

Comparison

Authentication via API

Instead of logging in through the user interface, Playwright also supports authentication using backend APIs.

This approach is faster because it avoids UI interaction entirely.

Authentication is typically performed using:

request.post()

After receiving the authentication response, the session is stored using Storage State and reused across all subsequent tests.

When API Authentication Is Useful

API authentication becomes especially valuable when the application's login page contains a CAPTCHA.

According to your project notes:

• Production environments keep CAPTCHA enabled.
• QA environments either disable or bypass CAPTCHA.

Common Approaches

• Disable CAPTCHA through a feature flag in QA.
• Authenticate using APIs and reuse the session.
• Mock CAPTCHA validation.

Among these approaches, API login combined with Storage State provides the cleanest automation solution.

FAQs

What is Storage State in Playwright?

Storage State captures browser authentication information, including:

• Cookies
• Local Storage
• Session Storage

The information is saved using:

storageState()

and stored in a JSON file for later reuse.

How do you log in once and reuse the session?

• Perform login using the UI or an API.
• Save the browser storage using:

context.storageState()

• Store the session as a JSON file.
• Create new browser contexts using the saved file.

Every test starts with an authenticated session.

Why should sessions be reused?

Session reuse:

• Eliminates repeated login.
• Reduces execution time.
• Improves automation stability.
• Makes regression testing faster.

What is the difference between Cookies and Local Storage?

Cookies

• Small storage
• Expire automatically
• Sent to the server with every request
• Primarily used for authentication

Local Storage

• Larger storage
• Does not expire automatically
• Not sent to the server
• Used for client-side application data

How do you authenticate using APIs?

Authenticate by sending a login request using:

request.post()

After successful authentication, save the browser session using Storage State and reuse it across all tests.

How do teams handle CAPTCHA during automation?

Common approaches include:

• Disabling CAPTCHA in QA environments.
• Logging in through backend APIs and reusing the authenticated session.
• Mocking CAPTCHA validation.

Production environments continue to use real CAPTCHA protection.