Multi-Line Log Parser

Exceptions are multi-line by nature. A java.sql.SQLException arrives as a headline followed by a tower of at com.example... frames and a Caused by: chain; log4j wraps a single message across several lines; Python prints a full traceback from Traceback (most recent call last): down to the raised exception. Splitting such a file naively by newline — in a spreadsheet, a log viewer, or a shell one-liner — destroys the story: one exception becomes a dozen unrelated rows, none of which mean anything on their own. Multi-Line Log Parser puts the story back together, entirely in your browser.

Tell the parser where entries begin — an ISO timestamp (2025-06-11T10:00:01Z), a bracketed timestamp ([2025-06-11 10:00:00]), a leading log level (ERROR/WARN/INFO...), a line that opens with a JSON brace, or your own regular expression — and every following line that does not itself look like a new start is attached to the entry above it. Blank lines inside a stack trace stay part of that entry too, so the line count you see matches what was actually in the file. The result is a table of whole events, not fragments: each row carries its start line number, the detected timestamp and level, a truncated headline for scanning, and the total number of lines — headline plus every continuation — that make up that entry.

This matters most when triaging incidents. A raw log tail interleaves exceptions from many different requests; without reassembly you cannot tell which stack frame belongs to which failure, or how many lines a particular crash actually spans. Once entries are rebuilt you can scan the level badges, search across full bodies including deeply nested frames, and immediately see which exception recurs most often.

Lines that appear before the very first matching start — a banner, a partial line left over from log rotation, output from a tool that does not use your chosen start pattern — have nothing to attach to. Rather than merging them into whatever entry comes next (which would corrupt that entry’s body), the tool lists them separately as orphan lines so you can see exactly what was left over and decide whether the start pattern needs adjusting. The level mix across all reconstructed entries is summarized as color-coded badges with percentages, live search filters the table by headline, body text, detected time or level as you type, and every entry can be exported with its full multi-line body intact — as CSV for a spreadsheet or JSON for a script. Nothing is uploaded: the log never leaves the tab it is pasted into.

• Multi-line reassembly — continuation lines, including blank ones inside a stack trace, reattached to their owning entry.
• Start-pattern presets — ISO timestamp, bracketed timestamp, log level, JSON brace.
• Custom regex preset for application-specific entry markers like ^>>> or ^\[PID:\d+\].
• Timestamp & level detection per reconstructed entry, independent of which start pattern is active.
• Orphan lines listed separately with their original line numbers, never silently merged or dropped.
• Live search across headlines, full stack bodies, detected time and level.
• Line-count column shows exactly how deep each entry runs.
• Summary cards for entry count, total lines, continuation-line volume and the deepest single entry.
• Level-mix badges with percentages across all reconstructed entries.
• Copy CSV / Download CSV / Download JSON / print export with full multi-line bodies preserved.
• 100% local — no upload.

1. Paste your log. Drop the raw dump — stack traces, crash logs, log4j output, anything that spans multiple lines per event — into the box.
2. Pick the start pattern. Choose ISO timestamp, bracketed timestamp, log level, JSON, or supply a custom regex that matches your application’s own entry marker.
3. Parse. Each entry is rebuilt from its start line plus every line that follows until the next match; the table also re-parses automatically as you edit the input or change presets.
4. Read the summary. Cards report entry count, total lines, continuation-line volume and the deepest entry; the level profile shows the mix as color-coded percentages.
5. Check orphans. If “List orphan lines” finds lines before the first recognized start, review them — they usually mean the pattern needs adjusting.
6. Search. Filter the table by exception text, stack frame content, timestamp or level.
7. Export. Copy as CSV, download CSV / JSON with full bodies intact, or print the table.

Example 1 — ISO timestamps. Lines beginning 2025-06-11T10:00:01Z start entries; the at AuthService.java:42 lines that follow, plus any Caused by: chain, are reattached to the exception that produced them.

Example 2 — Bracketed times. [2025-06-11 10:00:00.123] prefixed lines group into entries with the timestamp column populated automatically from the bracket contents.

Example 3 — Level starts. If your log starts each record with ERROR / WARN / INFO rather than a timestamp, the level preset groups and color-codes them in one pass.

Example 4 — Custom marker. A service that prefixes records with >>> or a request id like [req-8842] can reuse the same workflow through the Custom regex preset instead of one of the built-in options.

Example 5 — Mixed noise. A log rotated mid-write can leave a partial stack frame at the very top of the file with no start line before it; that fragment is reported as an orphan instead of being glued onto the next unrelated entry.

• Whole events — exceptions and multi-line messages come back as one coherent record instead of scattered rows.
• Flexible starts — timestamp, level, JSON or a custom regex covers most log formats without preprocessing.
• Orphans surfaced instead of silently merged into the wrong entry.
• Accurate counts — line and continuation totals reflect every line in the file, including blank ones inside a trace.
• CSV / JSON export with full multi-line bodies intact.
• Private: reassembly happens entirely in the browser.