Prompt Diff & Compare

Prompts are code, and code deserves version control

A modern prompt — the system prompt behind a Custom GPT, the instructions on a Claude Project, the standing message of an AI agent — is rarely written once and left alone. You ship a first draft, watch how the model behaves, and then tweak: tighten a rule here, soften the tone there, add a guardrail, delete a sentence that confused the output. After three or four rounds of this, your prompt has quietly drifted, and the honest answer to "what actually changed between Tuesday's version and today's?" is usually a shrug. That shrug is expensive. When a prompt suddenly starts producing worse answers, the regression almost always lives in a single edit you made and forgot. Being able to lay two versions side by side and see exactly which words or lines moved turns debugging from guesswork into a five-second read.

This is the same discipline software engineers have used for decades. Nobody reviews a code change by re-reading the whole file; they read the diff — the handful of lines that actually changed — because that is where the risk and the meaning live. Prompts behave identically. A prompt is a behavioural specification written in plain language, and the difference between "always answer in bullet points" and "answer in bullet points" can change every response the model gives. A diff makes those small, high-leverage edits visible instead of letting them hide inside a wall of unchanged text. Treating your prompts as versioned artifacts — keeping the old copy when you change something, and comparing before and after — is the single cheapest habit that separates people who tune prompts deliberately from people who poke at them and hope.

What the highlights are really telling you

Under the hood this tool computes a longest common subsequence between your two texts — the largest run of tokens (words or lines) that appears, in order, in both. Everything outside that common backbone is either an addition that exists only in the Changed version or a deletion that existed only in the Original. That is the same core algorithm behind the diffs you see in Git, code review tools, and document version history, and it is precise: it finds the minimal set of changes rather than just flagging "these two texts are different". Word granularity is perfect for catching a reworded instruction or a flipped constraint; line granularity is better when you have reorganised whole sections and want to see structural moves without the noise of every shuffled word.

Reading a diff well is a skill worth building. Additions in green tell you what new behaviour you are asking for; deletions in red, struck through, tell you what you have taken away — and removals are where silent regressions hide, because it is easy to delete a guardrail and not notice the model has stopped refusing something it used to refuse. Pair this tool with deliberate versioning: keep a short changelog of why each edit was made, run a diff before you commit to a new version, and you build a feedback loop where every change to a prompt is intentional, visible, and reversible. The same workflow applies far beyond prompts — comparing two drafts of an email, two revisions of a policy, two answers from different models — anywhere you need to know precisely what moved. It all happens locally in your browser, so even sensitive prompts and proprietary text never leave your machine.