For years, my answer to a 30 GB file was to use a different computer
I work on a Mac. I also keep a Windows PC on my desk, and for a long time one of the main reasons was a text editor.
Part of my job is software engineering in consumer data processing. Files in the tens of gigabytes are a normal week, not an emergency. And whenever one of them landed, the Mac stopped being the machine I worked on. I'd move the file over to the Windows box, open it in EmEditor, get my answer, and come back.
That went on for years. I never really tried to solve it on the Mac, because I already had a solution and it was sitting right beside me.
What these files actually look like
When people say "large file" they usually mean something a laptop struggles with for a few seconds. That isn't the category I'm talking about.
A production log with 80 million lines. A consumer record export with two million rows and fifty columns. A fixed-width file from a vendor with no delimiter at all. A SQL dump that's mostly one enormous INSERT. Files where the size is only half the problem, because the other half is that the encoding isn't what the vendor said it was, the header row lies about the column count, or a delimiter shows up inside a quoted field about four million rows in.
The request that stands out came from one of our attorney clients in North Carolina. He wanted to know whenever someone he had previously represented picked up a new ticket, which meant building a master file of his prior clients and matching every new day's records against it. The raw material was historical extracts from the state, and the state publishes two kinds of files, criminal and infractions. Inside each file there are multiple record types, add records, delete records, attorney records, hearing records, offense records, each with its own fixed-width layout, all living in the same .txt file. You cannot split a file like that on a delimiter because the layout itself is the delimiter, and it changes row to row. A five year extract arrived as about a dozen files at 2 GB and up. The job was filtering record types apart, pulling the records tied to his cases, and building a master file clean enough to match new records against every day after. All of that happened in EmEditor, on the Windows machine.
A synthetic extract in the shape of the state files: case, offense, event, witness, and attorney records interleaved in one fixed-width text file, no delimiters, each record type its own width. Layout modeled on a state court extract; all data fictional.
What everybody tells you to use
If you ask how to open a huge file on a Mac, you get the same answers, and they're good answers.
less opens anything instantly:
less huge.logIt's instant because it doesn't read the whole file. It reads the part you're looking at. That's the correct design for a pager and it's why less will still be here long after most editors aren't.
grep is right when you already know your search string:
grep -n "ERROR" huge.log > errors.txtAnd if the job is going to repeat, DuckDB or one of the CSV toolkits will chew through a multi-gigabyte file without loading it into memory:
duckdb -c "SELECT count(*) FROM 'export.csv' WHERE status = 'FAILED'"None of that is wrong. I'd recommend all of it. But I should be honest about my own history here: I never really ran that gauntlet. I was already paying for a Windows editor that did the whole job in one place, so the file just went to the other machine. I wasn't looking for a Mac editor that could handle this. I'd stopped assuming there'd be one.
Why the terminal answer doesn't cover the whole job
The reason isn't speed. It's that the commands assume you already know what you're looking for.
Most of the time I don't. The actual work is iterative. I filter to one condition, look at what came back, realize the interesting thing is a different condition, filter again. Each round trip through grep is a new command and a new output file, and after five of those I've lost track of which file is which.
The same file filtered to one defense attorney's records in Caxton: 233 of 20,000 lines, original line numbers kept, the whole file still one document.
Then there's the part where you need to change something. Not extract it, change it, and save the file back. A find and replace across a million occurrences that you can undo if it was wrong. A column of two million values sorted by number rather than by string, because sorted as strings, 100 comes before 99.
And there's verification. When you replace something across a huge file, you want to know exactly how many sites changed, and you want to see them. "It probably worked" isn't good enough on a file you're about to hand to someone.
That's the shape of the gap. Read-only inspection on the Mac is solved and has been for decades. Iterating, editing, and verifying at that size is not.
The file went to the other machine
So the file went to Windows.
EmEditor has been the answer in this category for a long time. It's built for exactly this work, and Emurasoft documents support for files up to 16 TB, which tells you how seriously they take it. It's also Windows only, and has been for its entire existence.
What actually kept me paying for it year after year was a two step habit. I would clean the file up in text mode, fixing delimiters and stripping the record types I did not need, then switch to CSV mode and look at the same file as a table. Fix it as text, read it as a grid. Once you have worked that way, an editor that only does one half feels like half a tool.
The cost of that arrangement isn't dramatic. It's just constant. Move the file across. Switch machines. Do the work in a different OS with different keybindings. Come back with a result. Keep a second computer partly alive for one category of task.
To be fair, the switching itself was never the nightmare it sounds like. I run Synergy, so one keyboard and mouse drive both machines and moving to the Windows box meant sliding the cursor over, not getting up. The friction was everything around that. Copy and paste between the two systems never worked right, so nothing moved by clipboard. Files moved over a network drive mapped to our file server, and on the hardware we had on site at the time, pushing a multi gigabyte extract across and pulling the results back was where the afternoon went (significantly better now). None of it was hard. It was a tax on every one of these jobs, paid twice, once in each direction.
I don't think I'm unusual here. Every thread I've ever read about opening huge files on a Mac ends the same way. Someone recommends less. Someone else says EmEditor and gets told it's Windows only. The thread stops.
Why nothing on the Mac did it
This isn't a story about bad Mac software. It's a story about a design decision that's correct almost everywhere except here.
Most text editors load the document into memory. For source code that's exactly right. You want the whole file addressable, you want fast edits anywhere, and a 4,000 line Swift file costs nothing. That model just doesn't survive contact with 10 GB, because the ceiling becomes how much RAM you have.
The tools that do handle the size tend to give something up in exchange. Dedicated log viewers handle enormous files and are read-only by design. Hex editors handle enormous files and show you hex. Pagers handle enormous files and aren't editors.
So there's a gap, and it isn't anybody's fault. It's just a workload nobody on macOS built for.
What I ended up building
I got tired of paying that tax, so I spent the past year building the editor I kept wishing existed. It's called Caxton.
The core of it is that files are memory mapped rather than read into memory, on top of a piece table document model with a tiered line index. Opening a file copies nothing. You pay for the part you look at, not for what the file weighs. It's native AppKit and Swift, no Electron.
The people from those cases, boiled down to a master table and opened as a typed grid: 233 rows, 13 columns. All data fictional.
On my test machine, an M1 Max with 64 GB of RAM, a 10 GB log with 80,610,954 lines opens immediately and finishes indexing in the background in 19.5 seconds. A full file search returns 1,613,344 matches in 1.3 seconds. Replace All across all of those lands in 1.7 seconds as a single undo step. Memory stays under 200 MB the whole time. A 2 million row CSV opens as a typed grid in 2.6 seconds and sorts by a numeric column in 8.2 seconds.
Those are my numbers from my harness on my machine, which is why the methodology is published: caxton.app/docs/benchmarks. Poke holes in it if you see any.
What still goes to the other machine
The Windows box is still on my desk. It just does a lot less than it used to.
EmEditor has macros and a plugin ecosystem, and a documented ceiling far past anything I've tested. If your workflow depends on those, it's still the tool, and I'd tell you so. Caxton is narrower on purpose. It opens the file, searches it, filters it, sorts it, edits it, and saves it back, on the machine I actually want to work on.
That's the whole pitch. For fifteen years the answer to this problem on a Mac was to not use a Mac. I wanted a better answer than that.
Caxton is a native macOS text editor for multi-gigabyte files. 7 day trial, no card: caxton.app