Log & Trace Analyzer
Open a huge log file — JSON/NDJSON, logfmt, syslog, or Java/app-server text — and get instant time-range narrowing, faceting, a timeline, request tracing, and full-text search, entirely in your browser with nothing uploaded.
Prefer the terminal? See the CLI equivalent →About the Log & Trace Analyzer
- Indexes big files in the tab
- Narrow to the incident window
- Facet & full-text search
- Correlate a request across services
- Query language & NDJSON/CSV export
- Instant results
- 100% private — runs in your browser
- Free, no sign-up
The Log & Trace Analyzer opens a large log file and lets you search, filter, and chart it without sending a single byte anywhere. It auto-detects the format — JSON/NDJSON, logfmt, syslog, or plain-text application logs like Spring Boot and WildFly, with multi-line stack traces kept attached to their record. Production logs are exactly the data you are usually not allowed to upload to a hosted service, so this runs entirely in your browser, indexing the file locally and keeping the raw bytes on disk rather than in memory.
It is built around the task you actually do: a ticket says “yesterday around 13:30 a user hit an error,” and you need to narrow a giant file to that window before you can read anything. A from→to time filter is the first-class control, with quick presets and a Local↔UTC toggle for the classic off-by-hours trap. Because logs are written in time order, that narrowing is a binary search over the timestamp column — instant even on millions of lines.
Once you are in the right window, filter by level, service, and host with one click, watch the timeline of what happened by severity, and search the message text of the narrowed set. Expand any record to read it as a pretty JSON tree. It is the difference between grep and a real query engine — without the log leaving your machine.
And when you find the failing request, correlate it: the analyzer auto-detects an id field (request_id, trace_id, correlation_id, and similar) and, from one click or a pasted id, reassembles that request’s entire journey across services — ordered by time, with the Δt between each step — so an interleaved multi-service log becomes a readable per-request trace that grep cannot produce.
How to use it
- Drop a log file — NDJSON, logfmt, syslog, or a plain-text app-server log — onto the box. The format is auto-detected and the file is indexed in a background worker with a progress bar.
- Set a From/To time range — type it, pick a preset, use “± N minutes around a point,” or brush the timeline. Toggle UTC/Local so the input matches your log’s zone.
- Click level, service, or host facets to narrow further; the counts show how much each value contributes to the current window.
- Search message text within the filtered set, then click a row to expand the full record as a JSON tree.
- Hit “Correlate” on a record (or paste an id) to see that request’s steps across services in time order, with the delay between each.
- Refine with the query language — e.g. level:error service:api -health "connection refused" — save the queries you reuse, choose your columns, drive the table from the keyboard, and export the filtered records as NDJSON or CSV.
How it handles large files
- Bytes stay on disk
- Only a byte-offset index and compact dictionary-encoded columns are kept in memory; record text is re-read from the File on demand.
- Time range is a binary search
- Chronologically-ordered logs narrow to a window in O(log n) — no full scan — so the incident-window filter is instant.
- Facets are bitset filters
- Level/service/host filtering is bitwise, so combining them stays fast even over millions of records.
- Search is facet-first
- Full-text search scans the already-narrowed subset in a worker, which is why filtering before searching feels instant.
Frequently asked questions
Is my log file uploaded anywhere?+
No. The file is opened, indexed, and queried entirely inside your browser tab — there is no server and no upload. That is the whole point: production logs are usually data you cannot send to a hosted service.
How big a file can it handle?+
Hundreds of megabytes. The raw text is never held in memory as parsed objects or one giant string; only a byte-offset index plus compact typed-array columns are kept, and rows are re-read from the file as you scroll. Indexing reads the file once with a progress bar.
What log formats are supported?+
NDJSON (one JSON object per line), logfmt (key=value), and plain text — the format is auto-detected from a sample of the first lines. For JSON and logfmt it finds common timestamp, level, service, host, and id fields; for text it matches built-in patterns (ISO-timestamp syslog like kern.log, RFC 3164 syslog, and timestamp+level lines such as Spring Boot, WildFly/JBoss, Log4j and Logback) and groups multi-line stack traces and property dumps onto the record they belong to. Timestamps may be ISO-8601, a "YYYY-MM-DD HH:MM:SS,mmm" Java timestamp, or epoch seconds/ms/µs/ns.
What can I type in the search box?+
A small query language: field predicates against the indexed columns — level:error, service:api, host:pod-1, request_id:abc* (trailing * is a prefix wildcard) — plus free-text words and "quoted phrases". Prefix any of them with - to negate, e.g. -level:info or -"health check". Field predicates are matched instantly on the columns; the text terms are scanned over the narrowed set. You can then export exactly what is shown as NDJSON (the original lines) or CSV.
Can it trace one request across services?+
Yes. It auto-detects an id field — request_id, trace_id, correlationId and similar — and correlates every record sharing that id into a single time-ordered trace, showing the gap between steps and which service each came from. Click “Correlate” on any record, or paste an id. It is a poor-man’s distributed trace built entirely from your log file.
Why does searching without any filter take a moment?+
Full-text search reads and scans the matching records’ bytes. If you have not narrowed with a time range or facets, that is every record, which takes a moment on a very large file. Narrow first — by time or facet — and search feels instant.
Why is the time filter off by a few hours?+
Almost always a time-zone mismatch: tickets are written in local time but log timestamps are usually UTC. Use the UTC/Local toggle next to the From/To inputs so they are interpreted in the same zone as your log.
Related tools
Code Formatter
Format and beautify JSON, YAML, TOML, XML, HTML, and CSS — with JSON/CSS minify and JSON schema validation.
Data Diff
Compare two JSON, YAML, or TOML documents by structure, not text: added, removed, and changed values with their paths. Key order and formatting are ignored. Runs in your browser.
HAR Viewer
Open a .har network export and explore its requests, sizes, status codes, and a timing waterfall — entirely in your browser. Nothing is uploaded.
JSON ↔ YAML ↔ TOML
Convert structured data between JSON, YAML, and TOML, live in your browser.
JSON to SQL
Infer a SQL CREATE TABLE from a JSON sample or a JSON Schema — column types, nullability, and a primary-key guess — for PostgreSQL, MySQL, or SQLite. Runs in your browser.
JSON to Types
Turn a JSON sample or a JSON Schema into TypeScript, Zod, Go structs, Python dataclasses, Kotlin data classes, or Java records/Lombok. Infers optional and nullable fields. Runs in your browser.