Log File Parser

Raw log files are walls of timestamps, levels and free-text messages. Paste an Nginx access log, an Apache error log, a syslog dump or a Laravel channel file and the parser splits it into structured rows, lets you filter by ISO date range, severity (DEBUG through EMERGENCY), client IP or regex against the message, and highlights hits so you can actually see what happened in the incident window.

How to parse a log file

  1. 1

    Paste log content

    Drop the raw log text. Common formats (combined, common, syslog, JSON-lines) are auto-detected.

  2. 2

    Set date filter

    Use a start/end timestamp to zoom in on the incident window.

  3. 3

    Filter by level or IP

    Tick severity levels, type an IP, or enter a regex pattern to match messages.

  4. 4

    Read the table

    Each row shows timestamp, level, source and message with matching segments highlighted.

Formats the parser recognises

Format Sample Source
Nginx combined 1.2.3.4 - - [18/Apr/2026:10:00:00 +0000] "GET / HTTP/1.1" 200 1234 web access logs
Apache common Same as above minus Referer and User-Agent classic LAMP stacks
Syslog RFC 5424 <34>1 2026-04-18T10:00:00Z host app - ID47 - msg Linux system daemons
Laravel daily [2026-04-18 10:00:00] production.ERROR: message Laravel log channel
JSON lines {"ts":"...","level":"ERROR","msg":"..."} structured loggers, Loki, ELK

Standard log levels

Listed loudest to quietest. Most apps follow the syslog / PSR-3 order:

  1. EMERGENCY, system unusable.
  2. ALERT, immediate action required.
  3. CRITICAL, critical condition, e.g. database down.
  4. ERROR, runtime error that should be investigated.
  5. WARNING, exceptional condition, not an error.
  6. NOTICE, normal but significant event.
  7. INFO, general operational messages.
  8. DEBUG, low-level diagnostic, noisy in production.

Filtering tips

  • Narrow by date first. Most production logs are huge; trimming to the incident window makes every other filter fast.
  • Use regex for messages. Searching for timeout|connection refused|5\d\d catches most network failures in one pass.
  • Isolate one IP. When investigating a suspicious client, filter everything else out and read their requests chronologically.
  • Exclude crawlers. User-Agent substrings like bot, crawl, spider filter out most noise from analytics-style investigations.

Performance notes

  • The parser runs client-side, so lines stay on your machine. That also means very large files (100 MB+) will slow the browser, split them first with split -l or stream them through a server-side tool.

Frequently Asked Questions

No. Parsing and filtering happen in your browser. The log you paste never leaves your device, which matters for files that may contain IPs, tokens or PII.

Yes, lines that start with whitespace or at ... are attached to the previous log entry, so a full exception stack stays in one row.

Use the regex filter against the message column. For structured JSON logs, all keys are searchable as plain text in the message.

Not directly, decompress first with gunzip or a file tool and paste the raw text. The parser expects uncompressed log lines.

There’s no hard limit, but anything over 10 MB may slow down filtering. For large archives, grep on the server first and paste the filtered output here.

Related Tools

Tool available in other languages