Minified JavaScript is unreadable by design. A source map is the index that reverses it: a JSON file mapping every position in the shipped bundle back to a position in a file that was never shipped - and, optionally, carrying the contents of those files inside itself.

That optional part is the whole subject. A map without it is a set of names and offsets. A map with it is your repository, served as a static asset.

The anatomy, and the field that matters

a source map, with the interesting fields kept

{
  "version": 3,
  "file": "main.a1b2c3.js",
  "sources": [
    "../src/lib/billing/stripeWebhook.ts",
    "../src/lib/internal/featureFlags.ts",
    "../../packages/admin-shared/src/roles.ts"
  ],
  "sourcesContent": [ "import Stripe from …", … ],
  "names": ["chargeCustomer", "isStaffOverride"],
  "mappings": "AAAA,SAASA,…"
}

sources

The original paths, relative. Names your folder structure, your internal package names, and often the shape of a monorepo you have never published.

sourcesContent

The files themselves. Comments, TODOs, commented-out code, the variable names you picked. This is the field that turns a map into a publication.

names

Original identifiers. Enough to reconstruct intent even when sourcesContent is absent.

mappings

The offsets. Useless alone, and the only part strictly required to symbolicate a stack trace.

A map is not automatically a vulnerability. It exposes no secret a bundle did not already contain - an API key in client code was public the moment it was bundled. What it exposes is structure and intent, which is a disclosure decision rather than a security bug, and it deserves to be made rather than defaulted.

Checking what a site actually publishes

Three states, and they are commonly confused with each other:

1. No map at all. No sourceMappingURL comment, nothing to fetch.
2. A comment pointing at a map that 404s. Generated, then not deployed - or deployed and later removed. Common, and the one people mistake for the first.
3. A comment pointing at a map that serves. Whether that matters depends entirely on sourcesContent.

which of the three, for every script on a page

for (const s of document.scripts) {
  if (!s.src) continue;
  const body = await (await fetch(s.src)).text();
  const ref = body.match(/sourceMappingURL=(\S+)/)?.[1];
  if (!ref) continue;

  const map = new URL(ref, s.src).href;
  const res = await fetch(map);
  console.log(s.src, res.status, res.ok
    ? ((await res.json()).sourcesContent ? 'full source' : 'names only')
    : 'referenced, not served');
}

Worth running on your own build after a config change. A bundler upgrade is the usual way this flips, in either direction, and nothing in the deploy output mentions it.

The three configurations that are defensible

Ship nothing

No map, no comment. Stack traces from production are unreadable and you accept that. Honest, and increasingly rare because error monitoring made the alternative cheap.

Build it, upload it, delete it

The one most teams want. The map is generated, sent to the error tracker at deploy time, then removed from the output directory so it is never served. Traces symbolicate; nothing is public.

Ship it deliberately

A defensible choice for an open codebase, a developer tool, or a team that considers its frontend source uninteresting. The point is that somebody decided.

the middle option, which is the one to copy

// vite.config.ts
export default { build: { sourcemap: true } };

// deploy step, in this order
// 1. build
// 2. upload dist/**/*.map to the error tracker
// 3. rm dist/**/*.map

// Deleting before uploading is the mistake to avoid,
// and it fails silently: traces stay minified and
// nothing in the pipeline reports a problem.

If you take the third option, take it completely. A half-published map - sources listed, contents stripped - gives an attacker your architecture and gives your own team nothing. It is the only configuration with no upside.

What it tells you about somebody else's build

Read from the outside, a map is one of the highest-signal artefacts a site publishes - not because of the source, but because of the sources array:

• The framework and its version, from the paths inside node_modules that survived bundling.
• The shape of the team. packages/admin-shared in a public bundle says there is an admin surface and that it shares code with this one.
• What was tree-shaken and what was not. A dependency in sources that no feature on the page uses is dead weight somebody is still shipping.
• Whether the build is what the site says it is. A page advertising one framework, mapping back to files from another, is a migration nobody finished.

None of that needs the source contents, and all of it survives sourcesContent being stripped. Which is the argument for the middle option one more time: the map you did not serve tells nobody anything.

Stack detection looks like pattern matching and mostly is. What separates a useful answer from a confident wrong one is whether the tool tells you how it knew - because the six kinds of evidence a page leaves are not equally reliable, and two of them are trivially faked.

The six, weakest last

A DOM marker

An attribute or class the framework itself writes - data-reactroot and its successors, a hydration marker, a generated class prefix. Strong: it is a side effect of the thing running, not a declaration about it.

A page global

A variable the library leaves on window. Equally strong, and often carries a version the page did not mean to publish.

A namespaced CSS variable

A custom property whose prefix belongs to one design system. Quietly one of the best signals, because it survives the minification that erases the others.

An asset URL

A script or stylesheet whose path names the thing. Good, with a caveat: a bundled copy under a hashed name says nothing, so absence here is not evidence of absence anywhere.

A response header

The server naming its own software. Reliable when present, and routinely removed, rewritten or set to something untrue as a matter of policy.

The generator meta tag

A declaration by the page about itself. The weakest of the six: a string somebody typed, surviving long after the thing it names was replaced, and the first thing edited by anyone who does not want to be identified.

The same six kinds, weighted by how hard each is to fake. The top three are side effects of code running; the bottom one is a sentence in the markup. - runs on the page itself.

The ordering is the useful part. Two tools can report the same name from the top of that list and from the bottom of it, and those are not the same finding.

the same claim, at both ends of the list

<meta name="generator" content="WordPress 5.2">

<link rel="stylesheet"
      href="/wp-content/themes/twentytwenty/style.css?ver=6.5">

<!-- The first is a string in a template, unchanged since 2019.
     The second is a file the server is really serving,
     and the two disagree by four major versions. -->

Why the evidence has to be shown

A flat list of names is not checkable. Told that a page is running a particular framework, you have no way to know whether that came from a hydration marker or from a meta tag somebody left in a template five years ago - and those two facts deserve different amounts of belief.

So every match here comes with the literal thing that matched and where it was found. It makes the readout longer and it is the difference between a claim and a finding.

It also makes the detector correctable. When a match is wrong, the evidence says which rule to fix rather than leaving somebody to guess at a heuristic they cannot see.

Absence is not evidence

The failure that produces confidently wrong readouts is not a bad match. It is treating a missing signal as a negative finding - and on a modern build, missing is the normal case.

Bundling

A library compiled into main.a1b2c3.js leaves no filename to match. It is running; the URL says nothing.

Minification

Class prefixes and global names are renamed. A framework can be present with every one of its usual markers gone.

Server rendering

Markup arrives fully formed. The runtime that produced it may never have reached the browser at all.

A stripped header

Removed as a matter of policy at more or less every serious host. Its absence is a security setting, not a fact about the stack.

So the honest output has two states rather than three: identified, with the evidence and not identified. There is no not present, and a tool offering one is telling you something the page did not say.

Versions, and what a version is worth

Where a page states a version, it is read and reported. Where it does not, nothing is invented - a guessed version is worse than a missing one, because the missing one prompts a question and the guessed one ends it.

Some versions cannot be told apart from the outside at all. Two major releases of the same tool can declare identical variable names, and a detector claiming to distinguish them is claiming something the page did not say.

Detecting yourself is the useful direction

The instinct is to point this at somebody else's site. The finding that changes a decision is usually on your own, because a stack list from the outside is a list of what actually reached a browser - not what the lockfile says, not what the bundler was configured to split, not what a colleague removed six months ago.

• A library everyone believes was dropped, still shipping in a chunk nothing imports any more.
• Two versions of the same framework, because a widget brought its own.
• A tag manager loading a second analytics vendor that no one on the team chose.
• A consent banner that itself loads three third parties before consent is given, which is the most common finding of all and the most expensive one.

That last one is worth checking on any site with a cookie banner. It is a compliance failure that is invisible from the inside and takes about four seconds to see from the outside.

What to do with the answer

The immediate use is orientation: opening an unfamiliar codebase's output before opening its source tells you what you are about to read.

The slower use is the third-party list. Most pages carry more analytics, tag managers, session replay and consent tooling than anybody on the team believes, because each was added once by somebody with a good reason. Seeing them named together, with the evidence for each, is usually the most uncomfortable part of the readout - and the most useful.