Use the free Log to Table Parser below: your data never leaves your browser — all work happens on your device, and nothing is uploaded to any server.
A log file is a story told in lines, but raw lines are hard to scan. Timestamps, severity words, and messages run together, and the one error you need hides among hundreds of routine info lines. The Log to Table Parser splits each log line into three columns, timestamp, level, and message, and shows the result as a table. Suddenly the story has structure: you can see when things happened, how severe they were, and what each step said.
The parser uses a regular expression that expects the most common log shape: a date and time, then a level word like INFO, WARN, or ERROR, then the message. Lines in brackets, such as [2025-03-01 10:00] ERROR, are handled too. Lines that match neither shape are not thrown away. They appear with empty timestamp and level cells and the full line as the message, so no information is lost even when the format is unusual. That fallback matters, because real logs are rarely perfectly uniform.
To use it, paste your log lines into the box. The sample shows a small server story: a start message, a warning about disk usage, an error, and a retry. Choose a level filter, or leave it on all levels, then press Parse log. The table appears below with counts: total rows, shown rows, and how many rows belong to each level. Press Download CSV to save the parsed table for a spreadsheet.
Filtering by level is the fastest way to triage. Errors first tells you what broke. Warnings next tells you what is close to breaking, such as disk usage at 82 percent in the sample. Info lines tell the story around the failure: what started, what retried, and what recovered. Reading in that order, errors, then warnings, then the surrounding info, usually finds the cause faster than reading from the top.
Counts also reveal patterns that single lines hide. Ten warnings about disk usage across an hour point to a slow leak, not a one-off spike. Errors that cluster at one minute point to a single event, such as a restart or a deploy. A table with counts turns that kind of pattern from a feeling into a number you can report to a colleague.
The tool has honest limits. It does not follow stack traces that span many lines, because each line is parsed on its own. A multi-line error will appear as one parsed row plus several fallback rows. It does not understand every log format in the world, and unusual timestamps may land in the fallback column. For a quick triage of common logs, though, it is fast and it never damages the source: the original lines stay untouched in the input box.
People use this parser to triage their own app logs, to turn a copied log from a support ticket into a readable table, and to prepare log evidence for a bug report. Because the work happens in the browser, logs that contain user names or internal paths never leave the device, and closing the page clears the paste from view.
How to parse a log into a table
- Paste your log lines into the box.
- Choose a level filter, or leave it on all levels.
- Press Parse log and read the table and the level counts.
- Filter to ERROR first, then WARN, to triage.
- Press Download CSV to save the parsed table.
Frequently asked questions
Why do some rows have empty timestamp cells? Those lines did not match the expected shapes, so the whole line was kept as the message instead of being dropped.
Can it handle multi-line stack traces? Only line by line. The first line parses normally and the following lines appear as fallback rows.
Which formats does it expect? A date and time followed by INFO, WARN, ERROR, DEBUG, or TRACE, or the same inside square brackets.
Is my log uploaded? No. Everything runs in your browser, and nothing is sent or stored.
Turn the wall of lines into a table, read the errors first, and let the counts tell you whether you are looking at one incident or a pattern.