Diff Studio
Git diff to animated video
Paste a diff or a commit URL and export an animated reveal as MP4 or GIF, entirely in your browser.
How it works
Parse
Files, hunks and line numbers, not just coloured text.
Compose
Drawn to canvas as a pure function of time.
Encode
Stepped frame by frame, so speed cannot cause a stutter.
Post
MP4 for social, GIF for readmes, WebM as a fallback.
Why Diff Studio
Code-image tools produce a still picture and know nothing about your diff; screen recorders produce a file the places you want to post it will not accept.
The beautiful-code-screenshot category is well served and entirely static. Those tools take a block of text and frame it; none of them know that your input is a diff, so a removed line and an added line are just differently coloured text rather than the thing the picture is about.
Recording the screen instead runs into two walls. The first is quality: a browser recorder runs on the wall clock, so if the page renders slower than real time the file stutters in proportion to how heavy the scene is. The second is the last mile, and it is the one that actually kills the share — X and LinkedIn do not accept WebM, which is what browser recording gives you for free. You finish the work and discover the file is useless.
So the export is stepped rather than recorded. The animation is a pure function of time, and the encoder drives it frame by frame with no reference to how long each frame took, which makes the result frame-accurate on any machine. MP4 is the default, GIF is there for readmes, and WebM is the fallback for browsers that cannot do the other two.
The export is the part everyone gets wrong
A stuttering WebM you cannot post is not an export. This renders offline and hands you an MP4.
| Capability | Elsewhere | Here |
|---|---|---|
| Understands it is a diff | No:Code framers treat the input as plain text | Yes:Files, hunks, renames, binary markers, line numbers |
| Animated output | Partly:Screenshot tools are still images | Yes:Lines land in sequence on a real spring |
| Exports a format X and LinkedIn accept | Partly:Browser recording gives WebM, which both reject | Yes:H.264 MP4 by default, GIF for readmes |
| Frame-accurate regardless of machine speed | No:Wall-clock recording stutters under load | Yes:Offline render, stepped frame by frame |
| Loads a commit straight from its URL | No:Paste-only | Yes:GitHub and GitLab commits and pull requests |
| Free and needs no install | Partly:The best recorder in this space is a paid desktop app | Yes:Runs in the browser, encoding included |
What it does
Paste a unified diff, or drop in a commit URL. It parses the change, then animates it — file headers arriving first, added and removed lines landing in sequence, the commit message as an optional title card. You get an MP4 or a GIF at the end, rendered entirely in your browser.
It is aimed at the thing every maintainer eventually needs and nobody enjoys making: a short, legible clip of a change, for a release note, a pull request, or a post.
Why the export format is the whole problem
Most browser-based recorders produce WebM, because that is what the built-in recording API gives you for free. X does not accept WebM uploads. Neither does LinkedIn. GitHub readmes want MP4 or GIF. So the file arrives at the exact moment it becomes useless, and the person who just spent ten minutes on it goes looking for a converter.
This exports H.264 MP4 by default and GIF for readmes, using the browser’s video encoding API directly. Firefox, which lacks part of that pipeline, falls back to WebM and is told so up front rather than after a forty-second encode.
Why it renders offline rather than recording live
The obvious approach is to play the animation and record the screen. It does not work: rasterising a page takes far longer than a sixtieth of a second per frame, while the recorder runs on the wall clock, so the result stutters in proportion to how complex the scene is.
Instead the animation is a pure function of time, drawn to a canvas and stepped frame by frame with no reference to how long each frame took. A slow render produces a slow export rather than a broken one, and the output is frame-accurate regardless of what your machine was doing at the time.