Split diffs are now available in Zed as the new default, starting from Zed v0.224. Open the project or branch diff, and you'll see the base text on the left, your working copy on the right, scrolling together in sync.
This was the top request after we shipped our Git integration in March 2025. Fair enough; a split diff view is a common feature and, when built well, should feel intuitive to use. But we know that intuitive feeling is hard-earned, and we wanted Zed's split diff view to match the rest of the editor: fast, minimal, and well-crafted.
The split diff view in Zed, showing several changes in the project diff
Building this new view was especially tricky because Zed's diffs aren't isolated file-by-file views. They're built on multibuffers, a single editable surface that spans multiple files. This meant we had to account for different challenges when crafting Zed's split diffs than other editors face.
In practice, that multibuffer foundation means you can move your cursor seamlessly between files, select text that spans file boundaries, and navigate through deleted regions just like normal text:
Freely moving the cursor through a multibuffer diff.
Zed's project diff, our main tool for reviewing changes, shows all changed files at once in a single multibuffer. This means the split diff view had to scale gracefully. And because of the unified nature of the multibuffer, a single misalignment can cascade through the entire diff.
What it looks like when the two sides of the split diff are misaligned---file content appears under the wrong header!
Making split diffs work within this world required solving these two hard problems: keeping the split view fast enough for large diffs, and keeping the two sides aligned on every keystroke.
Our split diff view looks like one multibuffer, but under the hood it's actually two.
Early on, we took a few stabs at modeling the left side multibuffer before we landed on a simple solution: we take the old version of each file, which is already used to calculate the diff, and just highlight each diff hunk's deleted part in red. This model is much more intuitive: there's one file on the left for each file on the right, and we can reuse its syntax tree and line numbers unmodified. By using a model that more closely matches users' expectations, we saved ourselves a lot of work patching edge cases.
With a good model in place, we moved on to the key UI problem for the split diff view: keeping corresponding lines on the two sides vertically aligned. This involves inserting spacers (empty visual regions, rendered with a subtle checkerboard) that pad whichever side is shorter. Fortunately, Zed already had the perfect mechanism for this: the block map, which lets us insert non-text decorations between actual lines of editable text. It's the same component that powers diagnostics and the inline assistant. The block map defines how these decorations interact with cursor movement, selections, and other core editor features so editing in a split diff view feels smooth.
The block map is designed to recalculate the positions of block decorations on every keystroke, and it's shared across all the files in a multibuffer, which makes it more performance-sensitive. Adding the spacers put more weight on the block map, so we had to optimize its performance so that Zed's diffs could scale to thousands of changed files. Hitting even the smallest lag, over and over, starts to get to you.
Here you can see a comparison between VS Code's and Zed's split diffs, where the view in the former gets out of sync when you edit, but in Zed, it stays perfectly aligned even as you type:
VS Code vs. Zed split diffs comparison.
Split diffs have to stay fast even on large changesets, so we tested against big diffs early and often. That profiling surfaced wins we didn't expect, including optimizations that had nothing to do with split diffs at all. Lukas and I found inefficiencies in the block map while optimizing view switching, and fixing those made project search faster, too. Jakub discovered that we were using the wrong process spawning API on macOS (fork/exec instead of posix_spawn), and fixing that reduced main thread hangs due to git blame and other external processes across the board. Now all multibuffers in Zed are faster on macOS as a result.
We made split-diff-specific optimizations, too (like doing less unnecessary work when constructing the view for the first time, and processing only the relevant parts of diffs when incrementally updating it), but those ended up mattering less than the broader improvements. Once you start profiling, you don't know where you're going to end up!
Split diffs are available in today's stable release, but our team is still finding performance gains that you'll enjoy in future weeks.
Zed's split diffs are fast on large changesets, they stay aligned as you type, and they feel like a natural part of our multibuffer experience. Open the project or branch diff and see for yourself. Split diff is the new default, but you can change back to unified diffs by changing your Diff View Style in settings. Let us know how it works for you on GitHub or in Discord.
Related Posts
Check out similar blogs from the Zed team.
Looking for a better editor?
You can try Zed today on macOS, Windows, or Linux. Download now!
We are hiring!
If you're passionate about the topics we cover on our blog, please consider joining our team to help us ship the future of software development.
Instagram Engineering
Shopify Engineering