A source map is a file — usually ending in .map — that maps your minified, bundled JavaScript back to the original source code you actually wrote. When your build tool crushes a hundred readable .ts files into one unreadable main.abc123.js, the source map is the key that turns it back.
That's incredibly useful while debugging. It's a problem when it's public in production.
What a source map actually is
When you run a production build, your bundler (webpack, Vite, esbuild, Next.js) does several things to your code: removes whitespace, shortens variable names, merges files, and strips comments. The output is small and fast but completely unreadable.
A source map records how that transformation happened. It's a JSON file containing your original file names, the original source text, and a mapping table that connects every position in the minified output back to a line and column in your original code.
You'll usually see a comment at the bottom of a bundle pointing to it:
//# sourceMappingURL=main.abc123.js.map
When DevTools sees that line, it fetches the .map file and reconstructs your original code in the Sources panel.
Why bundlers generate them
Debugging minified code is impossible — a stack trace pointing to main.js:1:48211 tells you nothing. Source maps exist so that errors, breakpoints, and the DevTools Sources panel show your original files instead. They're a development convenience, and most build tools generate them by default.
Why they're dangerous in production
A source map contains your original source code — not a hint of it, the whole thing. If the .map file is publicly reachable, anyone can:
- Read your entire frontend source in DevTools: component names, comments, business logic.
- Find hardcoded secrets far faster, because they're reading readable code instead of a minified blob.
- Understand your app's structure and spot weak points to attack.
Minification is often mistaken for protection. It isn't — and a public source map removes even that thin layer, handing back the original.
How to tell if yours are exposed
Open your deployed site, then DevTools → Sources. If you see original .ts / .tsx files instead of minified code, your maps are public.
Or check directly:
curl -I https://yoursite.com/_next/static/chunks/main.js.map
# HTTP 200 = exposed. HTTP 404 = safe.
Are source maps always bad?
No — source maps themselves are fine and useful. The problem is publishing them publicly. There's a safe middle ground used by most production teams: generate source maps during the build, upload them to your error tracker (Sentry, Datadog) so you still get readable stack traces, but don't serve them to the public web. You get debuggability without exposing your code.
How to disable them
The fix depends on your framework — usually a one-line config change. The full step-by-step for Next.js, Vite, CRA, Astro, Nuxt, Angular, and WordPress is here:
→ How to disable source maps in production
Once you've changed the config and redeployed, scan your live URL with vibeblame to confirm the .map files are gone.