How to open a large log file on macOS

Free, installed, works right now

Start in Terminal

less is on every Mac and has no practical file-size limit, because it reads only the part of the file it is currently showing. This works on a 50 GB file on a laptop with 8 GB of RAM.

less /path/to/huge.log

Inside it:

• G jumps to the end, g to the start
• /pattern searches forward, n and N move between matches
• &pattern shows only the lines that match — a filter, kept until you clear it with & and an empty pattern
• F follows the file as it grows, like tail -f; Ctrl-C returns to normal paging with everything you just watched still scrollable. Start that way with less +F file.log — note the plus. less -F with a minus is a different option entirely (“quit if one screen”)
• -N on the command line turns on line numbers, -S stops long lines wrapping

When you know what you are looking for, cut the file down instead of browsing it. The result is small enough for any editor:

# the last 500 lines
tail -n 500 huge.log

# follow a live file, surviving log rotation
tail -F /var/log/app/current.log

# pull every error into a file you can actually open
grep -n 'ERROR\|FATAL' huge.log > errors.log

# how big is it, really
wc -l huge.log && ls -lh huge.log

For searching, ripgrep is worth the one-line install. The grep that ships with macOS is the BSD one, version 2.6.0, which is old and has no PCRE support; rg is markedly faster on large inputs and searches a whole directory of rotated logs without any extra syntax:

brew install ripgrep
rg -n 'connection refused' /var/log/app/

If none of this is enough, it is usually for one of two reasons: you want to keep a filter and still look at what surrounds a matching line, or you want to watch a file live while searching what already went past. That is the point at which a viewer earns its place.

The thing everybody tries first

Why your editor can’t open it

A text editor is built to edit. That means holding the document in memory and building the structures editing needs — an undo history, syntax state, a map of every line so the cursor can be put anywhere. All of it scales with the size of the file, and none of it is free. Past a certain point the editor either refuses to open the file, opens it with most of its features switched off, or opens it and becomes unusable.

This is a design decision rather than a bug, and it is why the answer is a different kind of program rather than a bigger machine. A pager reads the bytes it is displaying. A log viewer memory-maps the file and indexes where the lines start, so the size of the file stops being the size of the problem.

Editors are what most people try second, and they fail in stages. First they switch their own features off — syntax highlighting, folding, wrapping — to stay responsive. Then they warn before opening. Then, at some size, they refuse or run out of memory, and where that point sits differs by editor and by version. The reason is the same throughout: an editor holds the document because it has to be able to change it, and that cost scales with the file. It is a reasonable design for editing and the wrong shape for reading a log — you wanted to look at the thing, and you are paying for the ability to rewrite it.

One more thing worth knowing, because it is the opposite of what people assume: Console will open a plain-text log — macOS registers Console as the owner of the .log file type, so double-clicking one sends it there. What you get is a bare read-only viewer. Console is built around the unified logging system, the stream you would otherwise query with log show, and none of that filtering applies to a plain file; Apple’s own Console documentation covers only log messages, activities and reports. So “my log opened in Console and it is useless” is the common experience, and it is not the tool you want for a multi-gigabyte file.

The options

What to use, and when

Versions, prices and licences checked 13 August 2026. These are statements about what each tool is, not benchmarks: the only application whose performance we have measured is our own, and its numbers are below with the machine and cache state they were taken on. Where a claim here is a vendor claim rather than something checkable, it is not in the table.

Choosing

A short decision list

• You need to look at it once, now. less. It is already installed, it opens anything, and it works over SSH where a GUI cannot go.
• You know the string you want. grep or rg into a smaller file, then open that anywhere.
• Your logs are structured and you want to query them. lnav. SQL over log records and timeline-merging several files is genuinely something no GUI here replaces.
• You want a free graphical viewer. klogg, if you do not mind that the stable build is from 2022 and runs under Rosetta on Apple silicon. Chipmunk is the actively developed free option and ships a native Apple-silicon build.
• You need to edit the file, not only read it. BBEdit. It has the best large-file reputation of any Mac editor and has a free mode, but it is an editor: it holds the document in memory because it has to be able to change it, and it has no level filters or follow mode.
• You are on a Mac and you do this often. A native viewer that keeps search, level and regex filters, context lines and follow mode in one window is worth an hour’s pay. That is what LogRider is for.

Ours

LogRider, and what it measures

LogRider is a native macOS viewer for logs too big to open: a C++17 memory-mapped engine under a real AppKit interface, read-only by design. It requires macOS 12.0 Monterey or later and ships as a universal binary for Apple silicon and Intel. It costs $19 once, and the trial is simply the download — 7 days, every feature unlocked, no card, no email and no account.

Opening a file builds a sparse line index first, and nothing is on screen until that finishes — there is no partial first screen, so on a very large file you wait, and then everything is fast. Figures below were measured on an M2 Max with 32 GB, on internal SSD, release build, in August 2026. They are Apple-silicon numbers.

The 4.9 GB file is larger than the page cache on a 32 GB machine, so storage is the ceiling for it; “cached” means the file was already in the page cache. We publish no MB/s figure, because cache state moves throughput by roughly 28x and a single number would be a cached measurement presented as a general one. Full feature list and screenshots are on the LogRider page.

What it does not do in 1.0, stated here so nobody finds out after paying: no file comparison or diff, no folder comparison or three-way merge, no Kubernetes log streaming, no syntax highlighting, no minimap and no custom highlight rules. macOS only — there is no Windows or Linux build.

Questions

Frequently asked