Guide

How to open a large file on a Mac

A 4 GB log, a database dump, an export that came off a mainframe. Here is what the tools already on your Mac can do with it, why most editors cannot, and what to use when you need to change a line and save it back.

First, the tools already on the machine

Before installing anything: macOS ships with tools that read a large file without loading it, and for a quick look they are the right answer.

• less bigfile.log — pages through a file of any size. G jumps to the end, /pattern searches forward. It reads as it goes, so opening is instant however big the file is.
• tail -f bigfile.log — the last lines, and new ones as they arrive.
• head -n 100 bigfile.log — the first hundred lines.
• grep -n "pattern" bigfile.log — matching lines with their numbers. rg (ripgrep) is faster if you have it.
• split -b 100m bigfile.log part- — chops the file into pieces small enough for an ordinary editor. It also leaves you with a directory of fragments and no way to save a change back.
• wc -l bigfile.log — how many lines there actually are, which is usually the first thing you want to know.

What none of them do is let you edit the file. That is the wall people hit: the log is readable in less, the fix is one line, and every editor on the machine either refuses the file or takes it as a hostage.

Why editors struggle where less does not

Most editors read the whole file into memory before showing you any of it, then keep a second copy for undo, and often a third decoded into the editor's own text representation. A 4 GB log therefore wants several times 4 GB of RAM before the first line appears. On a machine with 16 GB that is the beachball; on one with 8 GB it is the spinning fan and then a refusal.

Editors that stay responsive on large files do it by not doing that — reading only what is on screen, and working out the rest on demand. That is the whole difference, and it is why the same file that takes a minute in one editor takes milliseconds in another.

What to check before you pick one

• Does it open, or does it refuse? Some editors have a size limit and simply will not try.
• Does it stay usable? Opening is easy; scrolling to the end, jumping to line forty million and searching are where it shows.
• Can it save? A viewer is not an editor. Check that a one-character change writes back correctly, and that it does not rewrite the whole file to do it.
• Does it keep the file's character set and line endings? An editor that silently converts CRLF to LF, or a Windows-1252 export to UTF-8, has changed every line of a file you only wanted to fix one line of.
• How much memory does it use? Watch it in Activity Monitor while the file is open, not just while it loads.

Where Volt comes in

Volt was written for exactly this. Past a size you set — 64 MB by default — it does not read the file at all, and never builds a copy of it in memory, so a 4.23 GB log of 50.4 million lines opens in 2 milliseconds on a few megabytes of memory, and stays that quick when you jump to the end, search it and edit it. Below that size it simply reads the file, which for an ordinary one is faster than being clever about it. The status bar says which happened.

For scale, rg -F -j 1 — a dedicated search tool that does not have to keep an editable document — takes 1.55 s and 0.69 s on the same file and machine. Every figure comes out of Volt --benchmark, which runs on your own file. See the full measurements or everything it opens.

Questions