ByteScope

Large File Viewer

Open the 3 GB log that Notepad and VS Code give up on: scroll at once, search, filter like grep, read JSONL line by line. Nothing is uploaded.

The file is read in slices from your disk. Indexing, search and export run inside this tab — no upload, no account, no copy on a server.

Drop a log or text file here

Any size. Click to browse instead. .gz files are not supported yet.

About this tool

A server log is 3 GB and something went wrong around 02:14. Notepad hangs, VS Code warns and then stalls, and you do not want to scp the file around just to run grep. This page is a large text file viewer that opens .log, .txt, .jsonl, .ndjson, .csv, .json — any text file your browser can hand it, at any size — and never reads the whole thing into memory. You can scroll from the first line immediately, jump to a line number, a percentage or the tail, search for a request id and see the lines around every hit, or show only the WARN lines and save them as a new file.

How it opens a file that big

The file is read in slices, on demand. A background worker walks through it once and builds a sparse line index — one entry every 1,024 lines — so the page never needs the whole file in RAM. While the index is still being built the scroll bar works by byte position; once it finishes the scroll bar works by line number, and jumping to line N is exact. The character set is detected from the first 64 KB (UTF-8, UTF-16 LE and BE, Big5, GBK, Shift_JIS, EUC-KR, Windows-1252) and can be overridden if the guess is wrong. A single very long line — a 500 MB minified JSON on one line, say — is shown up to 1 MB and marked as truncated, and line numbers after it stay correct instead of the page crashing.

Search, filter and log levels

Search takes plain text, with case sensitivity as an option, or a JavaScript regular expression. The file is scanned chunk by chunk and results stream in as they are found; click one to jump there with its surrounding lines. A Stop button kills the search instantly — even a runaway regex — without losing the line index. The filter view shows only matching lines, or only non-matching lines like grep -v, listing up to 5,000,000 matches and telling you when there are more. Log levels are coloured automatically: ERROR, WARN, INFO, DEBUG, TRACE and FATAL words, syslog <N> priorities, the level or severity field of JSON logs including pino and bunyan numeric levels, logfmt level= and Android logcat, with a one-click "WARN and above". When the first 20 lines are all JSON objects or arrays the page switches to JSONL mode, where any line expands into a tree — only that one line is parsed. Filtered lines can be exported as a new file: on Chrome and Edge they stream straight to a file you choose, elsewhere the file is built in memory with a warning above 512 MB.

Honest limits

There is no full-text index in this version, so every search re-reads the file from start to end and its speed depends on your disk. This is a read-only viewer: to change bytes, open the file in Hex Editor. .gz files are not supported yet — decompress first. Regular expressions use JavaScript syntax, not grep or PCRE, so possessive quantifiers and similar features are unavailable. A single huge JSON document — one object or array spanning the file — is shown as text and is searchable, but is not rendered as a tree.

Privacy

Nothing is uploaded. The file is read in slices on your own device and the index, search results and filters all live in the tab. There is no server involved and closing the tab is the only cleanup.

Frequently asked questions

Why can't I open a 5 GB log in Notepad or VS Code?

Ordinary editors load the whole file into memory and build an edit buffer for it, which is fine at a few megabytes and hopeless at a few gigabytes. This page never does that: it reads the slice you are looking at, indexes line positions in a background worker, and searches chunk by chunk, so the file's size only affects how long a full search takes, not whether it opens.

Is my file uploaded?

No. The browser reads the file in slices from your disk and all the indexing, searching and filtering runs inside the tab. There is no server and nothing to send the file to. The exported filtered file is written straight to your own disk as well.

Why is the line count one higher than wc -l?

A line ends at \n, \r\n or a lone \r. wc -l only counts newline characters, so a file whose last line has no trailing newline is counted one short by wc -l. This page counts that final line too, because it is a real line you can read and search. If the file ends with a newline the two numbers agree; if it does not, this page shows wc -l + 1.

Can I jump straight to the end or to a specific line?

Yes. Jump to line N, to a percentage of the file, or to the end to see the tail. Before the background line index finishes, scrolling works by byte position; once it is done, line numbers are exact. The index is sparse — one entry per 1,024 lines — so it is small even for files with hundreds of millions of lines.

How do I show only the errors, like grep?

Use the filter view: type a plain string or a JavaScript regex and choose matching lines or non-matching lines (the equivalent of grep -v). For log levels there is a one-click "WARN and above" that uses the detected level of each line — plain words, syslog priorities, JSON level/severity fields, logfmt and logcat all count. Up to 5,000,000 matching lines are listed, and the result can be saved as a new file.

Can it read JSONL or NDJSON logs?

Yes. When the first 20 lines are all JSON objects or arrays the page switches to JSONL mode. Each record stays on its own line for scrolling and searching, and you can expand any line into a tree — only that one line is parsed, so a file with millions of records costs nothing extra. Level colouring reads the level or severity field, including pino and bunyan numeric levels.

Does it open .gz logs or let me edit the file?

Not in this version. Compressed .gz files need to be decompressed first, and this is a read-only viewer — to change bytes, use Hex Editor. For a CSV you want to sort, filter by column or query with SQL, CSV Explorer is the better tool; for Parquet, see Parquet Viewer.

What happens with a file that is one enormous line?

A line is displayed up to 1 MB and marked "line too long, truncated"; the rest is skipped for display, but the line numbers after it remain correct, so a 500 MB minified JSON on a single line does not crash the page. A single huge JSON document is searchable as text but is not shown as a tree — the tree view is only for JSONL, where each line is its own document.