Skip to content

LogDive

Logs & Debugging

Find the signal buried in a wall of log lines.

45 tools · all free · no sign-up · no upload

Browse all tools →

    Files

    Drop log files or folders

    Plain text, .gz, or a mix — nothing leaves this tab.

    Drag in several folders at once, or — clicking either repeatedly adds to what's already loaded.

    Read-only. Nothing you paste ever leaves your device. Search history (up to 5 recent patterns) and your layout preferences stay in this browser's local storage only — never file names, paths or content.

    A free online log viewer and grep for .gz, .zip, .tar.gz, .7z and plain .log files

    LogDive is a browser-only log viewer and explorer built for the moment a support ticket hands you a zipped export of a dozen rotated log files and no shell to grep them in. Drop the whole folder in — plain .log and .txt files, .gz archives, whole .zip, .tar.gz, .tgz and .7z bundles, and the odd stray binary all mixed together — and search across every included file at once, with the same line numbers and match counts grep and zgrep give you for free. Nothing is uploaded: every byte is read, decompressed and searched inside this browser tab — the same browser-only architecture every tool on this site uses.

    Every browser-based log tool eventually hits the same wall: it can open one file, but a real incident hands you a directory — rotated app.log, app.log.1.gz, app.log.2.gz, and whatever else logrotate left behind. LogDive treats that directory as the unit of work. Drop the whole export in, and every plain-text and gzip file in it gets a real line count before you've typed a single search character — the same promise wc -l makes on a terminal. Binaries that sneak in with a .log extension are caught by sniffing their first bytes, not trusting the name, and are excluded from search by default rather than hidden or silently skipped.

    Large log files, without the wait

    There is no file-size limit to configure. A plain-text log is streamed rather than loaded whole, so a multi-gigabyte file opens on its first screen and reports its true line count without ever sitting in memory in full, and the viewer renders only the lines actually on screen — scrolling a 10 million line file costs the same as scrolling a short one. Up to 1,000 files can be open at once, each indexed on a background thread so the page stays responsive while a large directory is still being read. Gzip members are the one exception: a compressed stream cannot be read in place, so each is decompressed into memory once, and LogDive names the exact size and the ceiling if one is too large rather than freezing the tab.

    Grep on Windows, without installing anything

    Windows has no grep. findstr and PowerShell’s Select-String search plain text, but neither reads a .gz file, and a rotated log export is mostly .gz files. The usual answers are Git Bash, WSL or 7-Zip to extract everything first. LogDive is the fourth option: open this page, drop the folder in, and search it the way grep -rn would, on Windows, macOS or Linux alike. It also works as a quick way to analyse log files from a machine you cannot install tools on — a locked-down laptop, a jump host, a colleague’s desk. It is a viewer and a search, not a log analyzer: it does not parse fields, build charts or aggregate; it shows you the lines, with counts and line numbers, and lets you read around each match. To analyze log files further, copy the lines out, or copy the shown command and run it where a shell is available.

    Reading .gz log files without extracting them

    A .gz file is not an archive of many files, it is one file, compressed; a .tar.gz or .tgz is a tarball of many, compressed once. LogDive does not extract either to disk — it never writes anything — so there is nothing to clean up afterwards. Gzip members are decompressed in memory with the browser’s own DecompressionStream and searched in place; tarballs, zips and 7z bundles are expanded in memory into the file tree, each log at its original path. If you do want the extracted files, use gunzip, tar -xzf or 7-Zip; if you only want to read and search them, you are done once they are dropped in.

    Why the exact command matters

    Every search LogDive runs is shown as the literal shell command that produces the same result — grep or zgrep depending on whether any included file is gzip, -F when the search is a plain (non-regex) match, because that's what a literal search actually is. This isn't decoration: it means you can copy what LogDive did and re-run it in a real terminal against the full export, or hand it to a teammate who doesn't have LogDive open, and get the same answer. A tool that hides what it actually searched is asking you to trust a black box; LogDive shows its work on every keystroke. If a pattern is fighting you, the regex tester explains what it matches before you bring it back here.

    A worked example

    Say a ticket ships with app.log, app.log.1.gz and app.log.2.gz. Drop all three in, tick the boxes (or leave them all checked, the default), type ERROR, and LogDive streams back every matching line across all three files, grouped by file with a running count, exactly like zgrep -n ERROR app.log* would from a shell — except gzip decompression, line indexing and the search itself all happen inside your browser tab, and the equivalent command line is right there above the results to prove it. Once the matching lines are in front of you, the log extractor pulls the JSON, XML and stack traces out of them with long trace IDs kept exact.

    Further reading: the GNU grep manual, RFC 1952 (gzip file format), and DecompressionStream on MDN.

    Frequently asked questions

    Does anything get uploaded?
    No. Every file you add is read, decompressed and searched by a Web Worker running inside this browser tab. Nothing is ever sent to a server — that's a structural fact of how the tool is built, not a policy choice that could quietly change.
    Can it open .gz files without extracting them first?
    Yes. LogDive decompresses gzip files in memory using the browser's own DecompressionStream API, indexes the result, and reports both the compressed and decompressed size. There's a size ceiling on how much decompressed text stays in memory at once — hit it and LogDive tells you the exact size and the limit, rather than freezing the tab. A .gz made of more than one concatenated member (logrotate sometimes does this) decompresses only the first member in Chrome and Edge, and says so in the tree and the viewer — that's a limit of the browser's own decompression API, not something LogDive works around silently.
    Does it open .zip, .tar.gz, .tgz and .7z archives?
    Yes. Drop one in and LogDive expands it in the background, adding every log file it contains to the tree at its original path inside the archive — a support bundle's folder structure survives the round trip. Nested archives (a zip containing another zip, say) expand up to 3 levels deep; anything nested deeper is kept as-is rather than silently skipped, with a note telling you it wasn't expanded so you can drop it separately. .7z support runs on a real 7-Zip build compiled to WebAssembly, loaded only the moment a .7z file actually shows up — never on every visit.
    How big a file can it handle?
    LogDive streams every file rather than loading it whole, so a multi-gigabyte plain-text log opens instantly and shows its true line count without ever holding the whole file in memory. Gzip files are decompressed into memory once, since a compressed stream can't be read in place.
    Is there a limit on how many files I can add?
    1,000 files at a time. That's the point where a directory export stops being 'a support bundle' and starts being 'most of a repository' — past it, indexing that many files individually just takes real time no matter how it's built, so LogDive asks first rather than leaving the page looking stuck. Drop more than that and it offers to take the first 1,000 and skip the rest; cancel and narrow the folder instead if you need everything in it.
    Why does the folder picker only take one folder at a time?
    That's a browser limitation, not a LogDive one — a native folder-picker dialog can only return one directory per invocation. Drag several folders onto the page at once instead, or pick again; either way, each addition adds to what's already loaded rather than replacing it.
    Is it really read-only?
    Yes. LogDive only ever requests read access to the files and folders you give it, and no code path in the tool imports a write API. The footer pill in the files panel says read-only for the same reason the equivalent command is shown: so the claim is checkable, not just asserted.
    Why does the command say -F?
    Because a plain (non-regex) search really is a fixed-string search — grep's -F flag is what makes that literal, so showing it is what makes the displayed command match what actually ran. Turn on the .* flag to search with a real regex instead, and the command drops -F to match.
    Does it work in Firefox and Safari?
    Yes for plain-text search. Gzip decompression depends on DecompressionStream, which is supported in current Chrome, Edge, Firefox and Safari; on an older browser without it, LogDive tells you specifically that gzip files can't be decompressed while plain files keep working.

    Explore more tools

    JSON Log Extractor

    Pull every JSON, XML, JWT and stack trace out of a log, with long IDs kept exact.
    Universal Regex Tester & Builder

    Test and build regex for Java, Python, Go, JavaScript, .NET, PHP and grep — free, in your browser.
    File Checksum

    Checksum any file — even multi-gigabyte ones — with a measured progress bar and a working cancel, entirely in your browser.

    Last updated .