You receive an error report from production. The stack trace looks like this:
TypeError: Cannot read properties of undefined (reading 'map')
at r (main.abc123.js:1:45821)
at Object.e [as render] (main.abc123.js:1:52034)
at t (vendor.def456.js:1:8901)This tells you almost nothing. main.abc123.js:1:45821 means line 1, column 45821 of a minified bundle — one enormous line. You cannot find that location in your source code without a source map.
Stack trace beautification maps these minified locations back to readable source file paths, function names, and line numbers.
Why Stack Traces Are Minified
Production JavaScript is bundled and minified to reduce file size and improve load performance. Bundlers (webpack, Vite, esbuild, Rollup) concatenate all modules, rename variables to single letters, remove whitespace, and write everything to a single line.
This is great for performance but terrible for debugging. The original file names, function names, and line numbers are lost unless source maps are present.
What are Source Maps?
Source maps (.map files) are JSON files that describe the mapping between minified output positions and original source positions. They contain:
- sources — the list of original source files
- mappings — a compact encoding of position mappings (VLQ-encoded)
- sourcesContent — (optionally) the full content of each source file
A stack frame like main.abc123.js:1:45821 maps via the source map to something like src/components/UserList.tsx:87:12 — which you can actually find in your source code.
The Stack Trace Beautifier Workflow
1. Get the minified stack trace
Copy the stack trace from your error monitoring tool (Sentry, Datadog, Rollbar, Bugsnag) or from a browser console error report.
2. Get the source map
Source maps are generated by your bundler. Options:
- Hidden source maps — generated but not referenced in the bundle, kept private on a server
- Inline source maps — base64-encoded and embedded in the bundle (not recommended for production)
- Linked source maps — referenced by a
//# sourceMappingURL=...comment at the end of the bundle
For private source maps, download the .map file for the bundle in the stack trace.
3. Paste both into the beautifier
The DevHexLab Stack Trace Beautifier takes:
- The raw minified stack trace
- The source map JSON (or upload the .map file)
And outputs the mapped stack trace:
TypeError: Cannot read properties of undefined (reading 'map')
at UserList (src/components/UserList.tsx:87:12)
at renderWithHooks (node_modules/react-dom/cjs/react-dom.development.js:14985:18)
at mountIndeterminateComponent (node_modules/react-dom/cjs/react-dom.development.js:17811:13)Now you know: the error is in UserList.tsx at line 87, inside the UserList component.
Generating Source Maps in Your Build
webpack (webpack.config.js):
module.exports = {
devtool: "source-map", // full source map
// or "hidden-source-map" to generate without embedding the URL
};Vite (vite.config.ts):
export default defineConfig({
build: { sourcemap: true }
// or sourcemap: "hidden"
});Next.js (next.config.js):
module.exports = {
productionBrowserSourceMaps: true,
};Uploading Source Maps to Error Monitoring
The best workflow is to upload source maps to your error monitoring service as part of your CI/CD pipeline. Sentry, Datadog, and Rollbar all support source map uploads. This way, every captured error is automatically mapped to source-level stack frames in the monitoring dashboard — no manual beautification needed.
# Sentry CLI example sentry-cli releases files VERSION upload-sourcemaps ./dist
Conclusion
Minified stack traces are a fact of life in production web applications, but they do not have to stay cryptic. The DevHexLab Stack Trace Beautifier lets you quickly map production errors to source-level locations during development and incident response, before you set up automated source map uploads.