Explain a Code Error
Paste or drop a stack trace and find out what actually broke.
PDFs and images are sent to a server to be read. Word, Excel and PowerPoint files are opened here and only their text is sent. Nothing is stored.
Drop the error, the log, or a screenshot of it
A traceback, a build log, a console screenshot. Paste works too — the few hundred lines around the failure beat the whole file.
Reading it…
That didn't work.
- Why it exists
- Written for
PDFs and images are sent to a server to be read. Word, Excel and PowerPoint files are opened in this browser tab and only their text is sent. What is sent is used to answer that one request and is not stored. Nothing is kept after the answer comes back, there is no copy to come back to later, and no document here is ever used to train a model.
Keyboard shortcuts
- / or ⌘K
- Search every tool
- ⌘↵
- Run this tool, from anywhere on the page
- ⌘S
- Download the result
- ?
- Open and close this list
About the Pathine Explain a Code Error
A stack trace names the place where the program gave up, which is almost never the place where it went wrong. Drop one in — a traceback, a build log, a browser console screenshot, a failing CI job — and this reads it the way somebody who has seen it before reads it: what actually failed, which frame is your code rather than a library's, and what the message is really saying.
It takes text and log files, screenshots of a terminal or a developer console, and PDFs of build output. Nothing to configure and no language to pick: the language, the framework and the runtime are worked out from the trace itself.
It says what the error means and what would explain it. It does not claim to know your codebase, and where the cause is genuinely ambiguous it says which possibilities fit rather than picking one confidently — the difference between a useful reading of a trace and a confident guess is the whole value of it.
When you'd reach for it
A traceback with forty frames of library code
The frames that matter are yours, and there are usually three of them. This separates the error, the last line of your own code before it, and everything the framework did in between.
A build that fails only in CI
Paste the job log. Missing environment variables, a version resolved differently, a path that exists on one machine and not the other — these read differently to somebody who has seen them before, and that is what this supplies.
A screenshot of an error somebody sent you
A red console, a crash dialog, a failing test in an editor gutter. Drop the picture in: it reads what is on screen and explains it, which beats retyping the message to search for it.
An error in a language you do not write
A Java exception on a Python team, a Rust borrow-checker message when you write TypeScript. The message means something specific; this is faster than learning the dialect to find out what.
How to read an error with this
-
Drop the log in
A .log or .txt file, a screenshot of a terminal or console, or a PDF of build output. Up to 8MB — for a long log, the part around the failure is more useful than all of it.
-
Read what failed
The error itself, the frame where it happened, and which part of the trace is your code. The findings are ordered by what would change what you do next.
-
Check the confidence
A trace with a clear cause and a trace with four plausible ones look the same until somebody says which it is. That is what the confidence line and the unknowns list are for — read them before you act on the rest.
-
Ask about the frame you care about
Follow-up questions are answered from the log you sent. If the answer is not in there it says so, rather than reasoning its way to something plausible about code it has never seen.
Common questions
Will it fix the bug?
No, and it has not seen your code — only the log. It explains what the error means, which frame is yours, and what would produce that failure. Turning that into a change is still your job, and that is the honest division of labour here.
Is my log uploaded?
Text and screenshots are sent to a server to be read, and the page says so above the dropzone. Nothing is stored once the answer comes back. Logs carry more than people expect, though — connection strings, tokens, internal hostnames, customer identifiers — so read what you are about to send, the same as you would before pasting it into a ticket.
How much of the log should I send?
The failure and a few hundred lines around it beats the whole file. Sixty thousand characters is the ceiling, and a log that large is mostly startup noise the error has nothing to do with. Trimming it makes the answer better, not just smaller.
It gave a different answer the second time.
Where a trace genuinely has several plausible causes, different runs can lead with different ones. That is worth reading as information: an error whose explanation is stable is one where the trace is decisive, and one that moves around is one where it is not.
Can I paste text instead of dropping a file?
Yes — paste into the dropzone, the same as everywhere else on this site. For something you only need shortened rather than explained, Text Summarizer is the lighter tool.