How to Inspect and Debug Shared Storage in Google Chrome DevTools

As web platforms deprecate third-party tracking cookies to protect user privacy, Google Chrome and the Privacy Sandbox initiative introduced the Shared Storage API. Shared Storage provides sites with unpartitioned, cross-site key-value storage that cannot be read directly by client-side JavaScript. Instead, stored data is read only within isolated, secure worklets that output low-entropy or noise-infused results (such as choosing an ad creative via the Private Aggregation or Select URL APIs). Because client scripts cannot access stored keys directly, developers require Google Chrome DevTools to audit and debug Shared Storage states.

In this guide, you will learn how to inspect Shared Storage entries, modify keys, clear origin data, and monitor worklet operations using Google Chrome DevTools.

Understanding the Shared Storage API and Worklets

Unlike standard localStorage or sessionStorage, which are strictly partition-bound to the top-level origin, Shared Storage allows cross-site data sharing with strict privacy guarantees:

• Write Anywhere: Any document or embedded iframe can write key-value pairs into its own origin-scoped Shared Storage using window.sharedStorage.set(key, value).
• Isolated Worklet Reads: Data can only be read inside a registered worklet (sharedStorage.worklet.addModule()). The worklet processes the data inside a headless, isolated JavaScript execution environment.
• Controlled Output Gates: The worklet cannot send network requests or exfiltrate data to the main window. It can only emit results through privacy-preserving APIs like selectURL() (which returns an opaque fenced frame config) or privateAggregation.sendHistogramReport().

Because you cannot log values to the standard browser console using console.log(), Chrome DevTools provides a dedicated visual inspector inside the Application panel.

Locating Shared Storage in the Application Panel

To inspect Shared Storage entries for any webpage:

1. Open Google Chrome and navigate to the webpage or web application utilizing Shared Storage.
2. Open DevTools by pressing F12 or Ctrl + Shift + I (or Cmd + Option + I on macOS).
3. Click the Application tab located in the top navigation bar.
4. In the left sidebar, expand the Storage category.
5. Click the Shared Storage dropdown arrow.

DevTools lists all origins that have initialized Shared Storage on the current page, including the top-level page origin and any embedded third-party iframes.

Viewing, Filtering, and Refreshing Stored Entries

Select a specific origin under the Shared Storage menu tree. The main pane displays a data grid containing all stored keys and values:

• Key: The identifier string passed to sharedStorage.set().
• Value: The string payload stored against that key.

To analyze large datasets effectively:

1. Use the Filter input field at the top of the table to search for specific key names or substrings.
2. If your application writes data asynchronously during user interactions, click the Refresh icon (circular arrow) in the toolbar to synchronize the table with the active memory cache.

Adding, Modifying, and Deleting Shared Storage Keys

Chrome DevTools allows developers to manually manipulate the stored state to simulate different user profiles, experiment cohorts, or boundary test conditions:

• Add a New Entry: Double-click the empty row at the bottom of the grid. Type the key name, press Tab, enter the value string, and press Enter.
• Modify an Existing Value: Double-click any cell in the Value column. Edit the text and press Enter to commit the modification immediately.
• Delete a Single Key: Select the target row and click the Delete Selected (trash can) icon in the toolbar, or press Delete on your keyboard.
• Clear All Entries: Click the Clear All icon (circle with a slash) to wipe all key-value pairs stored under that origin.

Auditing Worklet Operations and Event Logs

In addition to inspecting static storage tables, you can monitor dynamic worklet activity and invocations in real time.

Click on the root Shared Storage item in the left sidebar (above the individual origin nodes). The main view displays the Shared Storage Events pane:

Column Name	Description
Access Time	The precise wall-clock timestamp when the storage call was executed.
Type	The API method invoked (e.g., documentSet, documentAppend, documentDelete, documentClear, or workletRun).
Owner Origin	The security origin that owns the underlying storage partition.
Parameters	The key, value, and arguments passed to the method call.

Select any event entry in the table to view the raw JSON payload and stack trace in the preview pane below.

Troubleshooting Common Shared Storage Errors

If Shared Storage fails to initialize or entries do not persist, verify the following configuration requirements:

• Secure Context Required: Shared Storage is strictly restricted to secure HTTPS origins. In local development, you must use https://localhost or configure test certificates. Calls executed over unencrypted http:// fail immediately.
• Permissions Policy Restrictions: If embedded iframes fail to access storage, check whether the parent document allows the shared-storage feature in its HTTP headers:

  Permissions-Policy: shared-storage=(self "https://trusted-partner.com")

• Privacy Sandbox Enrollment: In production environments, origins writing or reading from Shared Storage must be enrolled with Google’s Privacy Sandbox coordinator and pass attestation checks. Check the DevTools Issues tab for enrollment warnings.