How to disable source maps in Nuxt 3 production builds

Set sourcemap.client to false in nuxt.config

This is a fix note for one framework, not an explainer on what source maps are or why public maps matter. For that background, see Source maps and public exposure in vibe-coded apps. Here the subject is the exact Nuxt 3 config key and how to confirm the result on your deployed URL.

The key is sourcemap in nuxt.config.ts. It is an object with two separate settings: sourcemap.client and sourcemap.server. The client setting controls the browser-facing bundle; the server setting controls server code that never reaches the browser. To keep client source maps out of the browser, set sourcemap.client to false:

The client setting is the one that matters for public exposure, because that is the bundle a visitor downloads. The server setting affects code that runs on your server only.

• export default defineNuxtConfig({ sourcemap: { client: false } })
• You can also pass a single boolean, e.g. sourcemap: false, which applies to both client and server at once.
• A third value, 'hidden', generates the map files but omits the sourceMappingURL reference from the bundle. That is for uploading maps privately to error monitoring, not for shipping them where a browser can find them.

How a Nuxt project ends up shipping client maps

If the default is client: false, why does this surface at all? Because the value gets changed, and the change is easy to forget.

The pattern is the same one behind most launch-time exposure: the app runs identically whether maps are on or off, so the difference is invisible from inside the app and only shows up when someone opens the deployed assets in a browser.

• A developer flips sourcemap to true (or sourcemap.client to true) to debug a production-only issue, then ships before reverting it. The build still works, so nothing flags the leftover.
• A starter template, boilerplate, or AI-generated nuxt.config sets sourcemap: true as a single boolean to make debugging easier, which silently enables the client maps too.
• A plugin, preset, or build wrapper sets it, or a Vite-level sourcemap option gets added alongside the Nuxt key. Nuxt builds the client bundle through Vite and the server bundle through Nitro, so there are two layers where a map setting can be introduced.

Check the deployed public URL for client maps

The config is not the proof. The proof is what your hosting actually serves. Check the deployed build, not your local dev server, because dev always generates maps regardless of this setting.

Open your live site in a clean browser session, open DevTools, and look at the Network tab while the page loads:

You can do the same from the command line against your own URL: fetch a client .js asset and grep its tail for sourceMappingURL, then fetch the referenced .map path and confirm it is not a 200 JSON map. Run this only against your own deployment.

Note the distinction: a public client .js.map is the exposure that matters here. Server-side Nitro maps are not downloaded by browsers, so they are a smaller concern from the public surface, though you still would not want them in a shared artifact.

• Look at a production JavaScript file your app loads (the entry chunk under your build assets, typically something like /_nuxt/entry.[hash].js). Scroll to the end of the response body and check for a sourceMappingURL comment.
• A sourceMappingURL pointing at a .js.map file is the suspicious result. Request that map URL directly. If it returns 200 with JSON containing a sourcesContent field, your original client source is being served to anyone.
• The safer result: no sourceMappingURL reference in the client chunks, and requesting a guessed .js.map path returns 404 (or a non-map error page), not 200 with map content.

Set it explicitly, rebuild, redeploy

The fix is small, but the order matters.

What this does not cover: turning maps off does not minify or obfuscate away everything. Client JavaScript is still downloadable and readable, just harder to follow without the original source mapping. And this setting says nothing about other public artifacts. An exposed .env, a reachable .git directory, or a secret hardcoded in the client bundle are separate problems with separate checks.

• Set sourcemap.client to false explicitly in nuxt.config.ts rather than relying on the default. An explicit line documents intent and survives template merges and config edits that might otherwise re-enable it.
• If you need maps for error monitoring, use 'hidden' for the client instead of true, and upload the generated maps privately to your monitoring tool. 'hidden' produces the map files without leaving a public sourceMappingURL reference in the bundle, so the browser is not handed a link to them. You are then responsible for not deploying those generated files to a public path.
• Rebuild and redeploy. The setting only takes effect in a fresh production build, so confirm the running deployment is the new build, not a cached or previous one, before you re-check.

Where VibeCodeGuard fits, and what it does not prove

VibeCodeGuard's Launch Check scans the public surface, so it can confirm the external half of this fix: after you change nuxt.config and redeploy, it checks whether a client .js.map is reachable from the public URL. That is the verify step that catches a config change that did not actually take effect, or a build that still shipped maps. It looks at what an outside visitor can download, with severity and fix direction.

What it does not do is read your nuxt.config or your build pipeline. It cannot tell you why a map was public, only whether one is reachable now. Setting the key correctly and rebuilding is work you do in the project.

Next step: set sourcemap.client to false in nuxt.config.ts, rebuild and redeploy, then open one production .js chunk in DevTools and confirm there is no public .js.map behind it. Run a focused Launch Check against the public URL before sharing it, so a stray map shows up in your scan and not in someone else's.