You want to test a CSS fix against the actual production page — real data, real layout, real edge cases — without deploying anything. Chrome’s Local Overrides does exactly that: edit a live page in DevTools and have the edit persist across reloads, saved to your local disk, invisible to anyone else.

Set it up once

1. Open DevTools → Sources tab → Overrides sub-tab.
2. Click Select folder for overrides, pick any local folder.
3. Grant the permission Chrome asks for.

That folder is now where your overrides live — a plain folder on disk, nothing server-side, nothing anyone else can see.

Edit and persist

Open the Elements panel, or the Sources panel, edit CSS or JS directly in the browser like you always could — but now, instead of the change vanishing on reload, DevTools saves a local copy of that file and serves it back to you on every subsequent load, from that domain, until you turn overrides off.

For CSS specifically, the fastest loop is the Styles pane in Elements: click a property, change the value, and if overrides are enabled, it’s already persisted. For JS, use the Sources panel, edit the file, Cmd+S (or Ctrl+S) to save — you’ll see a purple dot on the file tab indicating it’s now an override.

Verify what’s actually being served

Sources → Overrides panel lists every file you’ve overridden, with a small purple/orange indicator. Right-click any request in the Network tab and check for the “overridden” marker in the response — this is how you confirm you’re looking at your edited version and not a stale cache serving the real one, which is a real trap: if the response looks unchanged after an edit, check this before assuming your edit didn’t work.

Where this earns its keep

• CSS fixes against production data. Test a layout fix against a real customer’s actual dashboard state instead of trying to reproduce their exact data locally.
• Debugging a third-party script. Override a vendor’s minified JS to add a console.log or comment out a line, and see what actually happens, without needing their source or a sandbox.
• Testing a fix before writing the PR. Confirm the fix works against the real page first, then translate the confirmed-working change into your actual source files. This turns “I think this CSS change fixes it” into “I know this fixes it” before you write the real diff.
• Working around a broken response header — mock a Content-Security-Policy header locally to test whether it’s the actual blocker, without needing server access to change it.

The limits, so you don’t get burned

• It’s local to you and this Chrome profile. Nobody else sees your overrides — not your teammate, not a screen-share viewer, not you on a different machine. Don’t confuse “I fixed it” with “it’s fixed” — the override is a draft, not a deploy.
• It persists silently. If you forget an override is active, you’ll be debugging a “bug” that’s actually your own three-week-old override serving stale JS. Check Sources → Overrides periodically, and clear ones you’re done with.
• It survives a reload but not a hard content change on the real site in a way that conflicts structurally — if the real page’s markup changes enough, your CSS override may stop applying cleanly, and it’ll look like the fix “broke” when actually the target it was written against moved.

Turning it off

Sources → Overrides → uncheck Enable Local Overrides, or just delete the specific file’s override from the list. Do this before you screen-share a debugging session, or you’ll spend ten minutes explaining why the page you’re showing doesn’t match what your teammate sees on their machine.

---