Drop in a log file and it detects the format, parses every line, extracts timestamps, levels, IPs and HTTP status codes, and gives you a timeline chart, filters, a searchable table and a patterns panel — all in the browser, with nothing uploaded.

Yes — the demo data buttons under the drop zone generate five realistic logs in your browser: an Nginx access log with a 28-minute 5xx incident and a vulnerability scanner, a systemd log with SSH brute-force attempts and an OOM kill, a structured JSON application log with trace IDs and stack traces, a Kubernetes log with probe failures and a container restart, and a deliberately messy mixed log with five different timestamp styles.

No. They are generated by JavaScript in your tab from a fixed seed, so the same button always produces the same log and nothing leaves the page. The timestamps are anchored to the last six hours, so the timeline always looks like something that just happened.

Yes — ✎ paste log text opens a box you can paste into. Handy for a few lines out of a terminal, a chat message or a ticket, where saving a file first would be silly.

The Nginx access log shows the tool at its best: the timeline has a visible error spike, the patterns panel surfaces the scanner IP hammering /wp-admin and /.env, and the status filter isolates the 5xx window in one click. The messy mixed log is the one to try if you want to see what happens when a file mixes formats — detection picks whichever style is most common and the rest falls back to timestamp-and-keyword extraction.

No. The file is read with the browser's FileReader API, parsed in JavaScript, and held in memory. There is no back end, no upload endpoint and no storage — which is the point, because production logs routinely contain customer IPs, tokens in URLs and internal host names.

Yes, once the page has loaded. Parsing, the chart and the demo generators are all part of the page, so you can disconnect and keep working — useful on a jump box or an air-gapped laptop.

Free, no account, no size limit imposed by us. One of a set of client-side tools at jasperbernaers.com/apps.

Auto-detected: Apache common and combined, Nginx access logs, syslog / systemd, JSON lines with any field names, and a generic fallback that pulls a timestamp and a level out of almost anything.

The first 200 non-empty lines are tested against each format's signature, and whichever passes on more than 30% of them wins. That means a file can start with a banner or a few comment lines without confusing it, and a log that mixes formats falls back to the generic parser rather than mis-parsing everything.

The generic parser still works. It looks for a timestamp anywhere in the line — ISO 8601, RFC 3339, YYYY-MM-DD HH:MM:SS, syslog-style Mmm DD HH:MM:SS or an Apache bracketed date — and a level keyword anywhere in the text. You lose the structured fields such as IP and status, and you keep the timeline, the level filters, search and export.

ISO 8601 and RFC 3339 with or without milliseconds and timezone, 2026-08-18 14:32:07, Apache's 18/Aug/2026:14:32:07 +0000, and syslog's Aug 18 14:32:07. Syslog has no year, so the current year is assumed — worth knowing if you are looking at a log from December in January.

From an explicit level field where the format has one (JSON level, syslog priority, a bracketed [ERROR]), otherwise from keywords in the line — CRIT, FATAL, ERROR, WARN, INFO, DEBUG, TRACE. For access logs the HTTP status code sets the level instead: 5xx is an error, 4xx a warning, 2xx and 3xx are OK.

Yes. It looks for the common aliases — message/msg/text, level/severity/lvl, timestamp/time/ts/@timestamp — and falls back to showing the raw JSON when none of them exist, so nothing is dropped.

Each physical line is treated as one entry, so a Java or Python traceback appears as its first line plus its at … continuations. The continuation lines usually have no timestamp and no level, which makes them easy to spot but does inflate the line count. Structured JSON logging, where the stack is a field, avoids the problem entirely.

Not directly — decompress first with gunzip -c app.log.gz > app.log, or paste the output. Rotated plain-text files (access.log.1) work fine; rename them to .log or .txt if the file picker filters them out.

One at a time. To analyse several together, concatenate them first — cat access.log.2 access.log.1 access.log > all.log — which also keeps them in chronological order, something the timeline depends on.

Every parsed timestamp is placed into a bucket, and each bar is stacked by severity: red for errors and critical, yellow for warnings, green for everything else. The shape tells you in one glance whether a problem was a spike, a step change or a slow ramp.

Chosen automatically from the span of the file: per minute under an hour, per fifteen minutes up to a day, per hour up to a week, per day beyond that. The label above the chart says which one is in use.

Click a bar and the table filters to that time window. That is the fastest triage path there is: see the red column, click it, read the twenty lines that actually matter instead of scrolling through fifty thousand.

The first and last timestamp that parsed successfully. If it looks wrong — a range of years in a file you know covers one day — you have either a syslog file spanning a year boundary or lines whose dates are being misread, and the messy demo log is a good way to see what that looks like.

Blank lines are skipped, and lines with no recognisable structure are counted but not given a timestamp. A large gap between the two numbers usually means the format was mis-detected, or the file mixes formats — in which case the generic parser is doing its best on lines it was not designed for.

Anything classified as ERROR, CRIT or FATAL, plus every 5xx response in an access log. Warnings cover WARN and 4xx. That mapping is deliberately blunt: a 404 is not a server fault, but a sudden wall of them is still worth seeing in yellow.

Each chip filters the table to one severity, and combines with everything else that is active. Clicking Error and typing timeout in the search box gives you error lines mentioning timeouts — which is usually the first question you have about an incident.

No — it is a plain case-insensitive substring match over the whole line, so it finds text in the message, the path, the user agent or the raw JSON. It is not a regular expression, which keeps it predictable when you paste in a URL containing dots and question marks.

Matches the client address extracted from access logs, and it matches on a prefix — typing 45.83. isolates a whole /16-ish range rather than one host. Load the Nginx demo, copy the scanner IP out of the patterns panel, and paste it in: everything it touched appears at once.

Access logs only. It narrows to a class of HTTP response: 5xx for server errors, 4xx for client errors, 3xx for redirects, 2xx for successes. Combined with a timeline click it answers “what broke, in that minute” without any grepping.

Two buttons: ⬇ .log writes the currently filtered lines back out as plain text, and ⬇ .csv writes the parsed fields — timestamp, level, IP, status, message — as a spreadsheet. Both respect every active filter, so what you see is exactly what you get.

Because once the fields are separated you can pivot on them. A CSV of the 5xx window opens in Excel or pandas and answers “which endpoint, which client, what time” in a couple of minutes — and it is the right thing to attach to an incident ticket, because the recipient does not need this tool to read it.

Not as a link — the log lives only in your browser, so there is nothing to link to. Export the filtered .log or .csv and send that. It is also the safer habit: you decide exactly which lines leave your machine.

For access logs: the top client IPs by request count, the distribution of HTTP status codes, and the most requested paths. For every format: the most frequent error messages, the spread of log levels, and the busiest source services. It is a triage summary rather than an analysis — it tells you where to look.

Look for one IP with a request count far above the rest, hitting paths your application does not have — /wp-login.php, /.env, /.git/config, /phpmyadmin — and getting 404s for all of them. The Nginx demo contains exactly that pattern so you can see the shape before you meet it in a real log.

Three common causes: a scanner (many different odd paths from one IP), a broken deployment (many requests for one asset path that no longer exists), or a bad link somewhere popular (one path, many different clients, often with a referrer). The top-paths list separates them immediately.

499 is Nginx's own code for “client gave up before we answered” — it usually means your upstream got slow and users hit stop. 502 and 504 mean the upstream failed or timed out outright. Seeing 499s ramp before the 502s is the classic signature of a backend saturating rather than crashing.

Filter to errors, look at the first red bar on the timeline, click it, then clear the error filter and read the surrounding lines. The interesting event is almost always the last normal line before the errors — a deploy, a config reload, a certificate renewal, a restart.

OOM kills (Out of memory: Killed process), units that failed and restarted (Main process exited, Scheduled restart job), repeated Failed password lines from one address, and disk or certificate warnings. The systemd demo includes all four.

There is no hard limit — the practical ceiling is your browser's memory, and files of a few hundred megabytes are usually fine on a desktop. Parsing runs in batches so the tab stays responsive, and the progress bar shows real progress rather than a spinner.

Rendering a hundred thousand table rows would freeze the page, so the table caps what it draws while the stats, timeline and patterns are computed over every line. Narrow with a filter or a timeline click and you are looking at all the matches that matter.

Cut it down before loading. grep -i error big.log > errors.log, or sed -n '/14:00/,/15:00p' big.log for a time window, or tail -n 200000 big.log for the recent past. You lose the full-file statistics but gain a much faster loop — and you can always load the whole thing afterwards once you know what you are looking for.

The file was larger than the available memory. Split it (split -l 500000 big.log part-), pre-filter with grep, or use a desktop tool for the first pass. A browser tab typically has a couple of gigabytes to work with, and a log line costs far more in memory as a parsed object than as text on disk.

It reads the file into memory and then parses in batches. That is what makes the timeline and the patterns possible over the whole file, and it is also why the practical limit is memory rather than time.

The tool never transmits your file — no upload, no API call, no storage. You can verify it: open the network tab and watch it stay empty while you load a file. That is the whole reason it exists, because production logs are exactly the thing you cannot paste into a cloud analyser.

No. Nothing is written to localStorage or IndexedDB. Reload the page and the log is gone, which also means nothing is left behind on a shared machine.

Privacy-first page-view counting with no cookies and no personal data. It records that the page was viewed; it has no access to the file you opened, which never leaves the JavaScript running in your tab.

More than people expect: client IP addresses (personal data under the GDPR), session tokens and API keys in query strings, email addresses in URLs and error messages, internal host names and file paths, and full stack traces revealing your dependency versions. Treat a log export with the same care as a database dump.

Filter to only the lines that matter, export that, and scrub what remains — sed -E 's/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/x.x.x.x/g' for IPs, and remove any token= or key= query parameters. Exporting a filtered slice rather than the whole file is already most of the work.

Under the GDPR, yes — an IP address is generally treated as personal data, which is why log retention periods and access controls matter, and why uploading raw logs to a third-party service is a decision rather than a detail.

The format was not recognised and no timestamp was found. Check the first few lines: if the timestamp is in a format not listed above, or the file is a CSV export rather than a log, the generic parser has nothing to grab. Search, filtering and export still work on the raw text.

Syslog lines carry no year, so the current one is assumed. A December log opened in January will look like it is from the future. Convert to ISO timestamps at the source (journalctl -o short-iso) and the problem disappears permanently.

Timestamps are displayed as they appear in the file. Most server logs are UTC, so if you are comparing them to your local clock they will look shifted. Apache and ISO formats carry an offset; syslog does not, so there is no way for the tool to know.

The lines contain no level keyword and no HTTP status. That is common for application logs that print bare messages. Adding a level to your log format is worth doing — it is the field that makes every downstream tool, including this one, useful.

It filters on .log, .txt, .json and .csv. Rename a rotated file (access.log.1 → access1.log), or drag it onto the drop zone, which accepts anything, or paste the contents.

Make sure you are dropping onto the drop zone itself rather than elsewhere on the page, and that the browser has not opened the file in a new tab instead — that happens when the drop lands outside the target. Clicking the zone and using the picker always works.

✕ clear resets everything and returns you to the drop zone. There is nothing cached, so a reload does the same thing.

Any current version of Chrome, Edge, Firefox, Safari, Brave, Opera or Vivaldi, on desktop or mobile. No frameworks and no external libraries. A phone will struggle with a very large file simply because it has less memory.

No, and it is not trying to. Elastic, Loki, Splunk and Datadog exist for continuous ingestion, retention, alerting and correlation across hosts. This is the tool for the file you already have in front of you — the one that arrived attached to a ticket, or that you pulled off a box five minutes ago, where standing up a pipeline would take longer than reading the log.