Python

Python Traceback Parser

Turns a wall of traceback text into a table and points at the deepest frame that is your own code.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Copy the whole traceback, starting at the "Traceback (most recent call last):" line, and paste it in.
  2. Leave the library field blank to use the usual defaults, or list your own path fragments separated by commas.
  3. Select Parse the traceback.
  4. Open the file named in the "Start here" row — the deepest frame that is your own code rather than a library.

What python traceback parser does

A traceback is read bottom-up, which nobody finds natural, and the frame that matters is usually neither the first nor the last. It is the deepest one that belongs to your own code — everything below it is a library doing what it was told with a value it should never have been given. This page lays the frames out as a table, marks each one as library or your code, and says which one to open first.

The library test is a list of path fragments, and it is editable, because what counts as third-party depends on how the project is laid out. The defaults cover site-packages, dist-packages, the standard library path and frozen importlib frames. Chained exceptions are handled too: when Python prints "During handling of the above exception", the block you care about is the last one, and the page says so rather than leaving you to work out which of two tracebacks actually stopped the program. Everything is parsed as text in your browser — no traceback is uploaded anywhere, which matters because tracebacks routinely contain file paths, usernames and argument values.

Frequently asked questions

The deepest one that is your own code. Everything below it is a library behaving correctly with a value it should never have received, so the fix almost always belongs at the boundary where your code handed that value over. The page marks that frame explicitly in a "Start here" row so you do not have to scan the paths yourself.

By matching path fragments — site-packages, dist-packages, the standard library path and frozen importlib frames are the defaults. That covers most layouts but not all, so the list is editable. If your vendored code lives somewhere unusual, put that fragment in the field and it will be treated as library too; clear the field entirely and every frame is treated as yours.

The last one. When Python prints "During handling of the above exception, another exception occurred", it shows the original first and the one that actually escaped last. The page counts those chains and says so in a Chained row, and it also lists every exception in the block in order, because the first one is often the real cause even though the last one is what stopped the program.

No. The parsing happens in your browser and this site is static files with no backend to receive anything. That matters more for tracebacks than for most inputs, because they routinely carry absolute file paths, usernames, hostnames and sometimes the values of arguments — none of which anyone wants to paste into somebody else's server.