Log Extractor

What gets logged, and why it's unreadable

A production incident rarely hands you clean JSON. It hands you a log line where the payload you need is squeezed between a timestamp, a thread name, a logger class and a sentence of prose — outbound request: followed immediately by an object with no space to breathe. A naive extractor that just counts { and } characters breaks the moment a string value inside that payload contains a brace of its own, which is common in exactly the kind of log people are debugging: a regex pattern, an error message that quotes malformed input, a stack-trace fragment logged as a string.

This tool starts from the same lossless JSON parser that runs every JSON tool on this site, asked from an offset in the middle of a much longer string rather than the start of a document. Because it's a real parser and not a scanner guessing at character counts, it knows the difference between a brace that opens a value and a brace sitting inside a quoted string, and it reports exactly where a payload ends.

Long trace IDs and order numbers survive

Every JSON extractor built on JSON.parse shares the same silent bug: a number past 2^53 — 9,007,199,254,740,991 — gets rounded to the nearest value a 64-bit float can represent, and the extra digits are gone for good. A Snowflake ID or an order number like 770368744177664001 comes back as 770368744177664000, which looks identical at a glance and is a different number. That is a serious problem in a tool whose entire job is helping you find and copy the ID you're chasing. This tool keeps the original characters: a number is only ever re-typed if writing it back out produces the exact digits you pasted, so long identifiers are returned unchanged.

JSON and XML, side by side

Enterprise integration logs are as often full of <soapenv:Envelope> as they are JSON, and XML gets the same care: the tool confirms a candidate element is genuinely well-formed — matching tag, valid attributes, a real closing tag — before reporting it as a find. That check is what keeps a stray <null> in prose, or a Java generic like List<String>, from being mistaken for the start of a tag.

Escaped and double-escaped payloads

The single most common real-world form is a payload logged inside a JSON field of its own, so it arrives as "payload":"{\"orderId\":123}" — quotes and braces escaped, unreadable at a glance. This tool unescapes it, re-parses the result, and shows it as its own find labelled unescaped. When a log shipper or sidecar re-logs an already-escaped line, the payload can arrive double-escaped; the same unescape step repeats until the text parses cleanly or genuinely can't, and the find reports exactly how many layers it peeled off. To unescape a payload by hand instead, paste just that field's value into the JSON formatter.

Truncated payloads

Logging frameworks cap message length — Logback's %.-4096msg, CloudWatch's 256 KB event limit, Splunk's default 10,000-byte TRUNCATE — so a payload cut off mid-write is the normal outcome for anything worth logging, not a rare edge case. A candidate that runs out of input rather than closing cleanly is still reported as a find, labelled TRUNCATED, with a plain diagnosis of exactly where it broke — "cut off mid-string inside items[3].name" — rather than being silently dropped. The tool does not guess at the missing characters and hand back a repaired payload; naming where it broke is a fact, and inventing what came after would not be.

Java toString() and Python dicts

A Java Map.toString() or Lombok @ToString logs as {orderId=123, status=PAID} — readable, but not JSON, and every value in it is unquoted, untyped text. Once the log is recognised as Java, this tool converts a Java map to JSON, inferring number versus string the same way the rest of this site does — a value is only read as a number if writing it back out produces the exact characters it started as, which is what keeps a 20-digit id or a zero-padded code as a string. The class name on a Java 16 record or a Lombok constructor is named in a caveat rather than silently dropped. A Python dict repr() like {'id': 1, 'ok': True} gets the same treatment once the log is recognised as Python — converting a Python dict to JSON online this way handles True/False/None, tuples and bytes literals, each flagged where it's lossy. Both readers only run once the log's own format is actually detected as that language, gated by the "Looks like…" banner above the results — a Java reader let loose on a Node log would be nothing but false positives.

Stack traces, log format detection, and correlation ids

A Java, Python, Node, .NET or Go exception is captured as a single find rather than forty separate log lines: the exception, its message, every frame, and the cause chain, with the first frame that's your own code — not a framework's — promoted to the top of the collapsed row. The same first pass that gates the reconstructions above reads the log's own shape — "Looks like Java · Logback", shown with its matched evidence lines so it's checkable in a couple of seconds, and "unrecognised" is a plain, first-class answer rather than a guess. Above 50 finds, payloads sharing the same structure are grouped automatically, and a group missing a field the largest one has is flagged — often the actual bug. Any traceId, requestId or similar id found on a line or inside a payload can be picked from the "Correlate by" menu to filter straight down to one request's events.

What gets reported, not just what gets extracted

Every scan reports how many lines and bytes it covered, how many payloads it found, and how many candidates it looked at but couldn't parse — a brace that turned out to be prose, a tag that didn't close cleanly. A tool that only shows you what it found, and says nothing about what it looked at and rejected, is not a tool you can trust about what it missed. If a scan hits its internal safety limits on a pathological input, that's stated too, rather than silently returning a partial result that looks complete.

Before you paste a log into a ticket

The most expensive thing in a log is rarely the payload you came for — it's the bearer token two lines above it, which is about to be attached to a Jira ticket that half the company can read. Because the tool has already read the whole file, it can say what's in there: how many JWTs, emails, password or token fields, AWS access keys, private-key blocks, card-shaped numbers and IP addresses it matched. Turn on Redact secrets and every one of them is masked everywhere the tool hands text back — on screen, in the clipboard, in a per-find download and in every export format, because a redaction that one download path forgets is worse than none. Download redacted log gives you a masked copy of the entire file rather than just the finds, generated in this tab: a "redact my log" service that uploads the unredacted log in order to do the work would be self-refuting.

This is pattern matching, and the page says so wherever it appears. It reports what it found; it never certifies what's left. A custom token format, an internal hostname, or a credential written into a sentence will not be caught, and no copy anywhere on this page will tell you a log is now safe to share. Redaction is also off until you ask for it — a tool that hides your own token from you in your own log reads as broken, and you'd go and paste the log into a worse one.

Comparing two payloads, and sending one onward

Once payloads are grouped by shape, the obvious next question is what actually differs between two of them. Tick Compare on any two JSON finds and the tool lists the JSON Pointers that differ: changed values, fields present on only one side, and an array that grew reported as one row rather than as every subsequent index having "changed". It compares the characters that were logged rather than the parsed values, so 1.20 and 1.2 are a difference — in a log they are — and a 19-digit id is compared digit for digit. The result copies as readable text or as a list of change objects; it is deliberately not called a JSON Patch, because it isn't one.

Every find can be sent onward: a JSON payload opens in the JSON formatter, an XML one in the XML to JSON converter, and a JWT spotted inside a payload in the JWT decoder. A whole shape group can be flattened to CSV — one row per payload, one column per leaf — and handed to the table workbench, which turns 1,180 near-identical payloads into something sortable. Anything too large for a link goes by way of the clipboard with a note saying so, rather than being quietly truncated on the way. All finds can also be exported at once as JSON, NDJSON or raw text, in source order, filters and grouping notwithstanding.

Multiple files, one scan

Rotated logs arrive as app.log, app.log.1, app.log.2 — drop all of them at once and they're scanned one after another, in the order you dropped them, which you can reorder before starting. Once more than one file is loaded, every find is tagged with the file it came from, so the results stay traceable back to a specific file even after they're mixed together in one list.

Big files, and your browser

A dropped file is handed to a Web Worker, which reads it as a stream rather than loading the whole thing into one JavaScript string on the page — the 40 MB log never sits in memory as a single value, so the tab stays responsive and the Cancel button actually works mid-scan. Log Extractor never uploads what you give it: reading, scanning and formatting all happen in this worker, on your machine, and there is no server for the file to be sent to. If your JSON is buried in a log rather than pasted whole, the JSON formatter and the XML to JSON converter are where an extracted payload goes next.