You double-click a 400 MB log file and your editor freezes, then crashes. Most editors load the entire file into memory and build line-index structures, so large files are slow or impossible. The solution is to use tools that read only the part you need.
First, decide whether you need the whole file
Often you do not. Questions like "what happened around 2 pm?" or "show me all the errors" can be answered without viewing the whole file. Narrowing first is faster than finding a magic viewer.
Command-line tools (the best option for big files)
These work on any file size because they stream the data:
tail -n 200 app.logshows the last 200 lines, usually where the latest problem is.tail -f app.logfollows the file and prints new lines as they are written (on Windows, PowerShell'sGet-Content app.log -Tail 200 -Waitdoes the same).head -n 100 app.logshows the beginning.grep "ERROR" app.logprints only matching lines. Add-C 5for five lines of context either side, and-ifor case-insensitive search.less app.loglets you page through and search without loading the whole file (on Linux and macOS; press/to search andGto go to the end).sed -n '1000,1200p' app.logprints a range of lines.wc -l app.logcounts the lines.
Windows users can use PowerShell equivalents, Select-String for searching and Get-Content -TotalCount or -Tail for ranges, or run these tools in the Windows Subsystem for Linux.
Cut a slice out
If you need to share or work on part of a file, extract it:
sed -n '/2026-10-02 14:3/,/2026-10-02 14:4/p' app.log > slice.log
This writes the lines from the first matching timestamp prefix to the second into a new, small file that any editor can open. You can also use split -l 100000 app.log part_ to break a file into pieces of 100,000 lines.
Editors built for large files
Some editors are designed to open huge files by reading them in chunks instead of loading them whole, and several log-specific viewers add colouring by level and live tailing. A general-purpose code editor may handle files up to a few hundred megabytes, but gets slow beyond that, so check the editor's documentation for its limits.
Why browser tools have limits
A browser editor holds the text in memory and renders it in a text area, which becomes sluggish well before it runs out of memory. Docento's Text & Markdown Editor caps files at 5 MB for that reason, and refuses larger ones with a clear message. Use it for slices and smaller logs, and use the command line for big ones.
Compressed and rotated logs
Old logs are often compressed (.gz, .zip). You do not have to decompress them to a new file first: zcat app.log.gz | grep ERROR or zgrep searches a gzip file in place, and gunzip -c app.log.gz | tail -n 100 shows the end.
Search tips
- Search for an error level or exception name first.
- Search for an ID from the failing request, which finds every line belonging to it across the file.
- Narrow by time range with a timestamp prefix.
- Exclude noise with
grep -v, for examplegrep -v "health check" app.log. - Combine filters with pipes:
grep ERROR app.log | grep "2026-10-02".
More search patterns are in how to search log files.
Prevent giant logs
- Turn on log rotation so files are capped by size or age.
- Use an appropriate log level in production; debug-level logging can produce enormous volume. See log levels explained.
- Ship logs to a central tool if you operate several services.
A caution about editing logs
Do not edit the log file in place while a program is writing to it, and avoid saving over it. Work on a copy.
Takeaway
Do not open a huge log in a normal editor. Use tail, head, grep and less to read only the part you need, slice out a window into a small file, and keep the Docento editor for logs under 5 MB.
