← Back to the Source Map Leak Checker
Opening a browser's devtools and looking at the Sources/Debugger panel is a real, fast way to spot the single obvious case: a map that is fully exposed on the exact script you happened to open. It is also the method most developers already reach for first, and it genuinely works for that case. This page is not affiliated with any browser vendor — it names browser devtools only as a generic manual habit, not a product being compared against.
| Check | Opening devtools by hand | This tool |
|---|---|---|
| Obvious fully-exposed map on the script you're looking at | Catches it | Catches it |
| A map reference that 404s/403s (stray but harmless) | Easy to misread as "no map" | Reports it separately as "blocked", distinct from "clean" |
| A vendor/third-party bundle with its own reference | Easy to skip — you're looking at your own entry bundle | Checks every script tag the page loads |
An inline data: URI source map | Easy to miss scanning network requests | Decoded and checked the same as an external map |
| Repeatable in CI on every deploy | Manual, point-in-time | CLI returns a real exit code |
| Distinguishes full source text from paths-only | You'd have to read the map JSON yourself | Reported automatically as a separate severity |
If you only need a one-off sanity check on a page you're already staring at in devtools, looking is fine — it's free and you're already there. The gap this tool closes is coverage: every script tag, not just the one you opened, checked the same way every time a deploy happens, with an exit code a CI pipeline can act on.
Open the Sources (Chrome/Edge) or Debugger (Firefox) panel on a live page: if a script's map is loaded, you'll usually see the original, readable file tree instead of the minified bundle. That is a fast, real signal for the single obvious case -- a map that is fully exposed on the exact script you happened to open.
Three ways this scripted check catches and a quick devtools look easily misses: (1) a script that references a map which 404s or 403s -- devtools just shows you the minified code with no indication of whether the reference itself is a stray leftover or was never a problem; you'd have to separately try to load the .map URL. (2) A vendor or third-party bundle carrying its own sourceMappingURL comment independently of your own build -- easy to skip when you're eyeballing the entry bundle you wrote and not the ten other script tags the page also loads. (3) An inline data: URI source map, which some bundlers embed directly in the script rather than as a separate file -- devtools will resolve it the same way, but a person scanning file sizes or thinking 'no separate .map request, so no map' would miss it.
A devtools check is a point-in-time, manual look. A deploy pipeline, a CDN config change, or a new vendor dependency can reintroduce an exposed map at any point after the last time someone happened to look. The CLI here returns a real exit code, so it can gate a deploy the same way a linter or test suite does -- catching a regression the day it ships rather than the next time someone thinks to check by hand.