ShipReady Guide · Launch polish · Vite · Next.js

How to Turn Off Public Source Maps in Production

Source maps turn your minified bundle back into readable source, which is great for debugging and also great for anyone curious about your code. If your production site serves .map files, visitors can browse your original files, comments and all. Here's how to check and turn them off.

5-minute readUpdated Oct 2026All guides

The short version

  • Check: if devtools shows your original src/ files on the live site, your source maps are public.
  • Vite: build.sourcemap is off by default. Make sure nothing turned it on.
  • Next.js: browser source maps are off unless productionBrowserSourceMaps is true.
  • Need them for error tracking? Upload them to your tracker, then delete them before deploying.

1. What a public source map exposes

Your production JavaScript is minified into something unreadable. A source map is a separate file that maps it back to your original code: real file names, variable names, comments and structure.

Your front-end code is already downloadable, so this isn't a disaster on its own. But it makes your code trivial to read and copy, and it exposes anything you assumed was hidden, like comments with internal notes or a hardcoded key in a file you thought was unused.

2. Check your live site

1

Open devtools on your live site

In Chrome, open the Sources tab. If you can browse folders like src/components with readable code, maps are being served.

2

Or check a bundle directly

Open one of your JS files and look at the last line. A comment like //# sourceMappingURL=index-a1b2c3.js.map points at the map. Try opening that URL.

3

Try guessing

Even without the comment, add .map to a JS file's URL. If it downloads, the file is public.

3. Vite

vite.config.ts
export default defineConfig({
  build: {
    sourcemap: false, // the default; make sure nothing set it to true
  },
});

sourcemap: "hidden" still writes .map files into dist; it only removes the comment pointing to them. If you deploy dist as-is, the files are still fetchable by name, so delete them after uploading to your error tracker.

4. Next.js

next.config.js
const nextConfig = {
  productionBrowserSourceMaps: false, // the default
};
module.exports = nextConfig;

If your config or an older template set this to true, remove it and redeploy.

5. Keeping readable stack traces

Error trackers like Sentry use source maps to turn minified stack traces into readable ones. You can have both: generate maps during the build, upload them to the tracker, and delete them before the files are deployed. Sentry's build plugins can delete the files after uploading for you.

Before you ship

  • No readable src/ folders in devtools on the live site.
  • Adding .map to a bundle URL returns a 404.
  • Build config has source maps off, or deletes them after upload.
  • No secrets anywhere in front-end source, maps or not.

Check your live site in 60 seconds

ShipReady scans your deployed URL and the JavaScript visitors actually download: leaked keys, Supabase exposure, unprotected API routes, titles and share images. Secret findings unlock only after you verify you own the site.

Free scan, no signup, no code upload.

FAQ

Is turning off source maps a real security measure?

It's hygiene, not protection. Anyone determined can still read minified code. The real rule is to never put secrets in front-end code at all. Turning maps off just stops making it easy.

Will I lose readable errors?

Only in the browser console. Upload maps to your error tracker and you keep readable stack traces there.

Keep reading

Remove console.log from production →Debug logs leak data and look unfinished. Strip them at build time and keep real errors.Which env variables are safe in the browser →NEXT_PUBLIC_, VITE_ and friends publish values to every visitor. Here's what's fine and what isn't.

Sources: Vite: build.sourcemap · Next.js: productionBrowserSourceMaps