Clean a stack trace before you share it
Runs locally in your browser. Your file never leaves your device.
By processing a file or pasted text here, you agree to the Terms.
…or clean a file instead
Pick a plain-text file (or drop one onto the box above). For whole log files, the log file redactor handles up to 20 MB.
Toggles are coupled to what this page adds on top of the shared detector
set: “Usernames in home paths” also masks bare mentions of a username
learned from a home path, and “Hostnames (contextual)” also covers
trace-specific contexts (host= keys, “on host …”,
DNS-resolution errors), bare mentions of learned hostnames, and the
possible-hostname review list below.
Review these — possibly internal hostnames
Hostname-shaped strings without strong enough context to mask automatically — in a trace they are just as often package names, module paths, or config keys, and only you can tell. They were not changed; their lines are marked in the cleaned pane below.
Review these — possibly secret
Random-looking strings that match no known secret format. They were not cleaned, because a high-entropy string can be a session token or just a checksum — only you can tell. Their lines are marked in the cleaned pane below.
Original
Cleaned
“It’s just a stack trace” is how the leak happens
A stack trace feels safe to share precisely because it looks like noise.
It is not noise — it is a structured description of your machine and
your org. Frame paths carry your OS username, which for most people is
their real name or their corporate login. The directories around it
spell out employer, project, and product names
(/home/jsmith/projects/acme-billing/…). Build-server paths
get baked into binaries at compile time and surface later on customer
machines. Exception messages are worse: that is where internal
hostnames, connection strings, ports, SQL fragments, and the occasional
password land, because whatever string the code was holding when it
failed is what gets printed. Package and namespace prefixes name your
internal architecture. One pasted trace in a public GitHub issue, a
forum thread, or an AI chat hands all of that to strangers — and
manual find-and-replace only catches the values you remembered to look
for, not the second hostname hiding in the third
Caused by:.
What gets masked
Usernames are taken from home-directory shapes —
/home/<user>, /Users/<user>,
C:\Users\<user> — and only the username segment is
replaced: /home/[USER-1]/app/src/main.py keeps the file and
line that make the trace worth sharing. A username learned that way is
also masked where it appears bare (“started by [USER-1]”),
with guards — minimum length and a common-account stoplist — so a user
named test cannot shred the text. Local paths outside home
directories collapse to a prefix token with the project-relative tail
kept readable: [PATH-1]/site-packages/requests/api.py still
says exactly which library failed, while the deployment layout in front
of it is gone; node_modules and site-packages
tails are never churned. Hostnames are masked only in strong contexts:
\\server UNC prefixes, host:port endpoints
with machine-name shapes, host=/hostname:
keys, “on host …” phrasing, and DNS-resolution errors
(UnknownHostException, ENOTFOUND). And the
whole shared detector set — emails, IPv4/IPv6, JWTs, AWS keys, Bearer
tokens, password=… values — runs over every line, because
exception messages are where credentials and connection strings leak.
Hostnames: conservative on purpose
In a stack trace, things that look like hostnames usually are not:
com.example.service.FooHandler is a Java frame,
requests.exceptions.ConnectionError is a Python module
path, spring.datasource.url is a config key. A cleaner that
masked every dotted name would destroy the trace. So this page
auto-masks only on strong context, and everything merely
hostname-shaped goes to a review list instead — flagged, never edited.
The honest consequence: internal hostnames in shapes this page does not
recognize — a bare machine name in prose, a plain-word service like
redis:6379, a Windows domain in
DOMAIN\user — will slip through. The
side-by-side preview exists so you catch them in seconds.
What it can miss — read this before you share
Detection is pattern-based and best-effort — expand for what can slip through.
Detection is pattern-based and incomplete by construction; this tool
does not parse any runtime’s trace grammar, and any tool claiming
complete detection is overpromising. Beyond the hostname caveats above:
project and org names inside the readable parts it deliberately keeps —
the tail of a home path or the project-relative part after a
[PATH-n] token — stay visible; extensionless directory
paths outside known roots are not masked; a spaced Windows username at
the very end of a path keeps its second word; POSIX paths containing
spaces are not detected; customer data quoted inside exception messages
is only caught when it matches a known secret shape; and random tokens
under about 20 characters slip beneath the suspicious-string flagger.
It can also over-mask: a URL route that looks like a filesystem path
may be tokenized — the safer failure. Review the preview, then share.
Cleaning a whole log file that happens to contain stack traces? The log file redactor takes files up to 20 MB on the same detection core.
Frequently asked questions
Does this page send my stack trace anywhere?
No. This is a static page with no server behind it, and its Content-Security-Policy is set to connect-src ‘none’ — the browser itself refuses to let this page make any network request, to us or to anyone. You can verify that: open DevTools, watch the Network tab, and paste a trace — no request carries your text. Cleaning runs in this tab’s memory and nothing persists after you close it.
What does a stack trace reveal about me or my company?
More than the error. Frame paths carry your OS username (often firstname.lastname), your directory layout with project and employer names in it, and build-machine paths baked in at compile time. Exception messages carry internal hostnames, connection strings, ports, and sometimes credentials or SQL. Package and namespace prefixes name your org. Any of that pasted into a public issue, a forum, or an AI chat leaves your control.
Can it miss internal hostnames?
Yes — deliberately. Dotted names in traces are usually Java packages, Python modules, or config keys, so only hostnames pinned by strong context (a \\server prefix, host:port, host= keys, DNS-resolution errors) are masked automatically. Everything merely hostname-shaped is flagged in the review panel instead, and internal hostnames in shapes this page does not recognize will slip through entirely. Read the preview before you share — that final human pass is the step no tool can replace.
Does it understand Java, Python, Node, or .NET trace formats?
It does not parse any of them — it treats the trace as plain text lines, which is why the same page works on a Java Caused-by chain, a Python traceback, a Node error, a .NET exception, or a log excerpt that mixes several. Line numbers, function names, frame order, and chained-exception structure pass through untouched; only the detected values inside the lines are replaced.
Why do repeated values get the same placeholder?
Each distinct value maps to a stable token like [HOST-1], assigned in first-seen order, and the same value always becomes the same token — including when your username appears in five frames or the same host shows up in a frame and again in the exception message. Whoever reads the cleaned trace can still follow the failure across lines; the value itself is gone.
Is there a size limit?
About 2 MB, which is far larger than any stack trace. Everything is processed in this tab’s memory. If you are cleaning a whole log file that happens to contain traces, use the log file redactor on this site instead — same detection engine, built for files up to 20 MB.