How to Debug Minified JavaScript Errors in Production

A JavaScript error captured in production almost always points at a minified, bundled file — something like main.a3f9c2.js at line 1, column 48291 — because production builds strip whitespace, rename variables to single letters, and often combine many source files into one, all specifically to reduce file size and improve load time. The problem is that this same optimization makes the error report essentially unreadable to a human trying to fix it.

The tool that solves this is a source map — a separate file, generated alongside your minified build, that records exactly how each position in the minified output maps back to a position in your original, readable source code. With the matching source map, an error at main.a3f9c2.js:1:48291 can be translated back into something like UserProfile.jsx, line 42, inside the handleSubmit function, exactly as it appears in your actual codebase.

Most modern build tools (Webpack, Vite, esbuild, and others) generate source maps automatically or with a simple configuration flag, but it's worth explicitly confirming this is enabled for your production build specifically — some default configurations only generate source maps in development mode, leaving production error reports untranslatable unless you deliberately turn source maps on for the production build too.

A common and reasonable concern is that publishing source maps publicly effectively exposes your original, unminified source code to anyone who looks for it — which is true, and is exactly why many teams generate source maps for every production build but don't serve them publicly from the same location as the JavaScript bundle itself, instead uploading them privately to an error-tracking service that can use them to translate stack traces without exposing them to end users.

Error tracking services like Sentry, Bugsnag, and similar tools are built around this exact workflow — you upload source maps to the service as part of your deployment process, and any error captured from real users automatically gets translated back to original source locations in the service's dashboard, without the source maps ever being served to the public.

If you're debugging a one-off production error and don't have a full error-tracking pipeline set up, most browser dev tools can still use a source map if it's accessible (even privately, via the right headers) to show you the original source directly in the debugger, letting you set breakpoints in your actual code rather than the minified bundle, exactly as if you were debugging in development.

As a completely separate, faster sanity check when you're staring at a stack trace and just need to understand what the minified code roughly does before waiting on proper source map tooling, running the relevant snippet through our Unminify JS / CSS / HTML tool at least restores readable variable spacing and formatting, which can make an otherwise-impenetrable minified snippet skimmable enough to spot the obvious issue.