Stack Trace Formatter

What it's for

Make a stack trace readable and find where it went wrong. Traces copied from logs, error reports and JSON often arrive on one line with \n written out, buried in library frames. This lays them out frame by frame, folds away the frames from libraries and the runtime, and, with source maps, shows where a minified JavaScript error really happened.

For example, when an error reporting tool gives you at e (main.3f2a.js:1:24519), add the build’s source map to see the original file, line and function.

How to use it

Paste a trace. JavaScript (Chrome, Node, Firefox and Safari styles), Java and Kotlin (with Caused by), .NET (with inner exceptions), Python tracebacks, Go panics, PHP and Ruby are recognised. Escaped \n and quotes, and traces run together on one line, are split up first.

Formatted gives the trace with each exception or cause under its message; Fold library and runtime frames (remembered) turns runs of node_modules, java., System., site-packages and similar frames into one line. The message names the first frame in your own code, the usual place to look. The table lists every frame.

For minified JavaScript, add the .map files: a frame whose file name matches a map’s file (or the map’s name without .map) gets its original place after an arrow.

Example

Press Try an example. The trace is a JSON string with escaped line breaks.

The message says JavaScript: 1 exception, 4 frames (2 in your code). Look first at getUser, line 14 in main.js. Formatted shows the TypeError and the frames getUser and async loadPage, then … 2 library frames for the React and <anonymous> ones.

Good to know

Which frames are “library” is a guess from paths and package names, so untick the fold if something seems missing. Source maps with sections (index maps) aren’t read, and a frame needs a line and column to be mapped. A trace in a format not listed above isn’t recognised.