Source Map Explorer — De-minify Production Stack Traces

Source Map Explorer

Resolve minified stack traces back to original source code using source maps.

Free online source map explorer and minified error resolver. Paste a production stack trace and upload your Source Map V3 (.map) files to de-minify and resolve cryptic function names, minified file paths, line numbers, and column offsets back to original TypeScript, JSX, or ES6 source coordinates. Inspect extracted source context (±3 lines) directly from embedded sourcesContent arrays. Group recurring exceptions by signature for rapid triage across Webpack, Vite, Next.js, Rollup, and esbuild bundles with 100% private in-browser processing.

Keywords: source map explorer, source map viewer, source map decoder, minified error resolver, minified stack trace, unminify stack trace, resolve minified javascript, sourcemap visualizer, decode sourcemap, production error debug, webpack source map, vite source map, source map debugger, original position lookup, javascript source map, resolve sourcemap, stack trace restorer, sourcemap error mapper

Tags: source-map, minified, debug, stack-trace, sourcemap, unminify

Browse all 41 Developer Tools tools →

Source Map Explorer is also known as: Source Map Decoder, Sourcemap Visualizer, JavaScript Stack Trace Unminifier, Source Map Resolver, Production Error Deminifier.

How to Source Map Explorer Online

  1. Upload your source map files (.map or .js.map) by dropping them into the upload dropzone or clicking to browse your local filesystem. You can upload multiple source map files simultaneously to cover app chunks, vendor libraries, and dynamic route bundles.

  2. Paste your minified production stack trace into the Stack Trace input field. This can be raw output from Chrome DevTools, Firefox, Safari, Node.js terminal logs, or error monitoring services (Sentry, Datadog, Bugsnag) containing minified tokens like `at r (main.a1b2c3.js:2:45678)`.

  3. Click the "Resolve trace" button or press ⌘↵ to de-minify the stack trace. The engine parses the Base64 VLQ mappings in your source maps and matches each minified frame against corresponding file coordinates.

  4. Inspect the resolved stack frames displaying original unminified file paths (e.g., `src/components/CheckoutModal.tsx`), precise line and column numbers, and original function/method identifiers.

  5. Expand any resolved frame to view surrounding original source code context (±3 lines) extracted directly from the embedded `sourcesContent` payload.

  6. Copy the unified error signature (e.g., `TypeError@src/lib/api/client.ts:42`) via ⌘⇧C for immediate bug triage in Jira, GitHub Issues, or Slack.

  7. If any frames display as "no-source-map" or "unmatched", upload the missing vendor or route-specific `.map` files generated during your production build.

Source Map Explorer Features

  • Source Map V3 Spec Support: Fully compliant with the official Source Map Revision 3 specification, parsing Base64 VLQ mappings and identifier names.

  • Multi-Bundle Mapping Engine: Seamlessly load multiple source maps (e.g., main app bundle, vendor chunks, shared libraries) with intelligent filename and basename heuristic matching.

  • Exact Coordinate Resolution: Converts 1-indexed browser runtime lines and columns into 0-indexed VLQ delta offsets to locate exact TypeScript/JavaScript source positions.

  • Original Identifier Restoration: Recovers original function, class, and method names from the source map `names` array whenever preserved by bundler manglers.

  • Embedded Source Context Extraction: Automatically retrieves and formats surrounding source code (±3 lines) with line markers directly from `sourcesContent` metadata.

  • Error Signature Normalization: Generates standardized error signatures (e.g., `ReferenceError@src/hooks/useAuth.ts:18`) to quickly identify duplicate exceptions across error logs.

  • Unmatched Frame Diagnostics: Distinguishes between native browser frames, unmapped runtime calls, and missing source map files with actionable visual status badges.

  • Flexible Ingestion Modes: Supports drag-and-drop file uploads, local system file selection, or direct pasting of raw source map JSON strings.

  • Multi-Bundler Compatibility: Works out-of-the-box with source maps generated by Webpack 5, Vite, Rollup, esbuild, Turbopack, Next.js, and SWC.

  • 100% Client-Side Privacy: All VLQ decoding, AST traversal, and stack trace parsing executes locally inside your browser memory — proprietary source code and map files are never transmitted to any server.

  • Comprehensive Frame Statistics: Real-time dashboard showing total frame counts, successfully resolved frames, unresolved coordinates, and active source map files.

  • Seamless Stack Trace Analyzer Pairing: Pair with the Stack Trace Analyzer to analyze error causes and de-minify code coordinates in one unified developer workflow.

Supported Formats & Dialects

The Source Map Explorer supports 6 syntax formats and dialects for accurate parsing and processing.

Source Map V3 (Standard Base64 VLQ)
The canonical JSON format containing `version: 3`, `file`, `sources`, `sourcesContent`, `names`, and comma/semicolon-separated Base64 VLQ `mappings` strings generated by modern bundlers like Webpack, Vite, Rollup, and esbuild.
Index Maps & Sectioned Source Maps
Multipart source maps structured with a `sections` array containing line/column offsets and sub-maps, commonly used in large code-split enterprise applications and multi-runtime bundle assemblies.
Inline Source Maps (Data URIs)
Source maps encoded directly as Base64 data URIs (`//# sourceMappingURL=data:application/json;charset=utf-8;base64,...`) at the footer of compiled bundles, typical in development servers and test runners.
TypeScript & Babel Transpilation Chains
Chained intermediate source maps mapping authored TypeScript (`.ts`/`.tsx`) and modern ESNext code through JSX transforms, Babel polyfills, and final minification passes into production bundles.
Hidden & Private Production Source Maps
Production `.map` files generated during CI/CD with `productionBrowserSourceMaps: false` or `--sourcemap=hidden`, kept off public CDNs for private error tracking and offline stack trace de-minification.
CSS & PostCSS Source Maps
Coordinate mappings linking compiled CSS utilities, Sass/SCSS partials, and Tailwind CSS generated rules back to original authoring stylesheet selectors and design tokens.
All Guides
All Standards
AI Model Token Pricing

Explore Full AI Model Pricing Directory

Compare per-token rates, prompt caching discounts, and context windows across leading LLMs (GPT-4o, Claude 3.5 Sonnet, Gemini 2.5 Flash, DeepSeek, and more) in our verified catalog.

Frequently Asked Questions

How does Source Map Explorer resolve minified JavaScript stack traces back to original TypeScript?
When JavaScript or TypeScript code is compiled for production, bundlers (such as Webpack, Vite, or esbuild) minify variable names, remove whitespace, and combine multiple source files into a single bundle line. During this process, the bundler generates a Source Map V3 (`.map`) file containing a Base64 Variable-Length Quantity (VLQ) lookup table. When you paste a minified stack frame like `app.min.js:1:38421`, the Source Map Explorer reads the generated line and column coordinates, decodes the corresponding VLQ 5-tuple, and maps it to the exact original file path (e.g., `src/utils/pricing.ts`), original line, column, and function name recorded in the source map.
How does Base64 VLQ (Variable-Length Quantity) encoding work in Source Map V3?
Storing raw line and column numbers for hundreds of thousands of tokens would produce multi-gigabyte source map files. The Source Map V3 specification solves this by encoding coordinate segments using Base64 VLQ with relative delta offsets. Each VLQ segment represents up to five values: (1) generated column delta, (2) source file index delta, (3) original line delta (0-indexed), (4) original column delta (0-indexed), and (5) optional identifier name index delta. Because each segment stores the difference relative to the previous token rather than absolute positions, values remain small and compress efficiently into 1 to 4 characters per mapping.
Why do browser stack traces report 1-based columns while Source Map V3 uses 0-based columns?
Web browser JavaScript runtimes (including Google Chrome V8, Firefox SpiderMonkey, and Safari JavaScriptCore) report line and column coordinates starting at line 1, column 1 in console error messages. In contrast, the Source Map V3 specification defines column offsets as 0-indexed (though lines are 1-indexed in certain tool representations). Source Map Explorer automatically normalizes browser coordinate offsets to match the 0-indexed VLQ specification, preventing off-by-one errors and ensuring accurate source line highlighting.
Why are original function names sometimes missing or showing as anonymous in resolved traces?
Original function names are restored using the `names` array in the source map. When minifiers like Terser, SWC, or esbuild mangle code with aggressive property and function name mangling (`mangle: true`), some anonymous function expressions or inline arrow functions do not retain distinct symbol names in the AST. To maximize function name fidelity in production error reporting, configure your bundler with `mangle: { keep_fnames: true }` or ensure your minifier preserves function declaration names.
How do I resolve stack traces when my project uses code splitting and multiple chunks?
Modern bundlers split applications into multiple asynchronous chunks (such as `main.js`, `vendor.js`, and dynamic route chunks like `814-5f4a.js`). Each compiled chunk has its own corresponding `.map` file (e.g., `814-5f4a.js.map`). You can upload all generated `.map` files simultaneously into Source Map Explorer. The resolver evaluates the filename and basename of each stack frame to match it with its specific source map consumer, resolving frames across all application chunks in a single pass.
What is the difference between sourcesContent embedded in the source map and external source files?
The `sourcesContent` field is an optional array in Source Map V3 files that contains the complete text of the original authoring source files. When `sourcesContent` is included by your compiler, Source Map Explorer can display the exact lines of code surrounding the crash (±3 lines) without needing access to your local filesystem or source repository. If `sourcesContent` was omitted during the build, the tool still accurately resolves file paths, line numbers, and column offsets.
How do hidden source maps protect proprietary code in production while allowing error de-minification?
Publishing `.map` files on public CDNs allows anyone to inspect your original TypeScript codebase and comments. Modern security best practice recommends using hidden source maps (e.g., `productionBrowserSourceMaps: false` in Next.js or `sourcemap: "hidden"` in Vite/Webpack). This generates `.map` files during your CI build without appending the `//# sourceMappingURL=` comment to public JavaScript files. You can save these `.map` artifacts securely in your build pipeline and load them into Source Map Explorer whenever you need to de-minify production error traces.
How does multi-step compilation (TypeScript -> Babel -> Bundler -> Minifier) affect source map accuracy?
When code undergoes multiple transformation steps (e.g., TypeScript compilation via `tsc`, transpilation via Babel, bundling via Webpack, and minification via Terser), each step produces an intermediate source map. If intermediate maps are discarded, the final source map will only point back to intermediate generated JavaScript rather than your original TypeScript. Modern build tools (such as Vite with esbuild or Webpack with `source-map-loader`) chain source maps automatically, producing a unified map linking the final bundle directly back to original `.ts` and `.tsx` sources.
Can I de-minify stack traces exported from error monitoring platforms like Sentry, Datadog, or Bugsnag?
Yes. You can copy the raw stack trace string directly from Sentry, Datadog, Bugsnag, CloudWatch, or browser console logs and paste it into Source Map Explorer. The parser automatically extracts error types, messages, file URLs, line numbers, and column positions regardless of whether the trace format originates from Chrome V8, Firefox, Safari, or Node.js.
How does this online Source Map Explorer guarantee source code privacy?
Source Map Explorer processes all source maps and stack traces 100% locally inside your web browser using WebAssembly and client-side JavaScript. Your `.map` files, unminified source code, proprietary algorithms, and error logs are never uploaded to any remote server or third-party telemetry service. You can even disconnect your internet connection after loading the page and the tool will continue functioning fully offline.

Developer Reference & Learning Hubs