Copy drift: what it is, what causes it, and how to prevent it

Copy drift is user-visible text diverging from its approved source across surfaces and over time, with no single source of truth to diverge from. The string is not missing and it is not broken — the wording itself changed, nobody decided that it should, and now the marketing page, the landing page and the product each say something slightly different about the same feature. globalize.now is a code-native copy management system with localization built in, and drift is the specific failure it exists to prevent.

What is copy drift?

Copy drift is user-visible text diverging from its approved source across surfaces and over time, with no single source of truth to diverge from.

Two halves of that definition do the work. Diverging from its approved source means somebody once agreed what this string should say. No single source of truth means there is no artifact that still holds the agreement, so there is nothing to diverge from in any checkable sense — which is why nobody can point at the moment it started.

Drift is normal, not exceptional. Any product with more than one surface and more than one person editing it will drift unless something structural stops it.

What copy drift is not

Three failures get lumped together and they need different fixes. Getting this wrong sends teams after the wrong problem.

A hardcoded string is text written directly into a component instead of a catalog. It is invisible to your tooling and to translation — but the wording may be perfectly correct. That is a different problem, and we covered it in why AI coding tools keep adding hardcoded strings.

Out-of-sync translation files are catalogs that exist and have fallen out of step with each other. The source is fine; the derived copies are stale.

Copy driftis neither. The string can be keyed, the files can be in sync, and the product can still say “Start free trial” in one place, “Try it free” in another, and “Get started” on the button that actually does the thing.

You can have all three at once. They do not fix each other.

What causes copy drift?

Three mechanisms, in rough order of how much damage they do.

Surfaces owned by different people, edited in different tools. Marketing copy lives in a CMS. The landing page is updated fastest because it is under constant experimentation. Product strings live in components. Each surface can be internally consistent while the product as a whole is not, and no single person sees all three in one sitting.

Small edits that nobody classifies as copy edits. Someone shortens a label to fit a mobile breakpoint. Someone sentence-cases a heading for consistency with a neighbouring screen. Each is defensible alone. None goes through anything resembling copy review, because to the tooling it is a string literal in a JSX attribute.

Coding agents. An agent asked to add a loading state may also rewrite a label while it is in the file — tidying a string looks exactly like tidying code. The community answer so far is a rules file: AGENTS.md, .cursorrules, a UI-copy policy block in the prompt. Those help and are worth having. But a convention is not a check. It reduces how often your copy gets rewritten; it does not tell you when it happened anyway.

Why doesn’t anything catch copy drift?

Because nothing breaks.

A changed label compiles. It renders. The type checker sees a valid string and the linter sees valid syntax. If a snapshot test fails, the normal response is to update the snapshot, which records the drift rather than flagging it. No build goes red, no alert fires, no dashboard turns amber.

Drift is only visible to something that knows what the approved wording was. Most toolchains hold no such record, so the first detector is usually a person — a support reply that quotes different words than the UI, a customer asking whether “Workspace” and “Project” are the same thing, or a translator asking which of three English phrasings to translate.

What does copy drift actually cost?

Honestly: nobody has measured it, including us, and we are not going to invent a figure.

That deserves saying plainly, because this category is full of numbers that do not survive contact with their source — survey figures about branding and revenue, per-ticket support costs, percentages of tickets attributed to inconsistent documentation. We have killed several of those internally rather than repeat them. The measurement that would actually answer this question — how much drift exists in real codebases, and what it does downstream — has not been done by anyone.

What can be described without a number is the mechanism, and the mechanism is compounding:

• It is invisible until it is expensive. Nothing surfaces drift while it is cheap to fix. It surfaces when someone needs the words to be the same, usually under time pressure.
• Every surface is a separate fix. Changing a phrase means finding every place it was restated, and there is no list of those places.
• Localization multiplies it. This is the sharp edge. Send three phrasings of the same idea to translation and you get three translations, in every language. An inconsistency that was contained in English is now replicated across your locale count, and it reads to a native speaker as three different features.

That last point is why copy consistency and localization are not separate projects. If you cannot say which phrasing is approved, you cannot translate any of them correctly — the source was ambiguous before the translator ever saw it. The architecture that fixes both is the same architecture, which we set out in code-native product copy.

How do you prevent copy drift?

Give the wording one home, and make changes to it reviewable. Everything else follows.

One catalog. Every user-visible string lives in one place rather than inline across components. There is now something to be consistent with.

Keys, not literals. Components reference a key instead of restating the words. The same phrasing cannot exist in two places and quietly diverge, because it only exists once.

Changes in the diff. A copy change shows up in review the way any other change does. This is the step that does the real work: consistency stops depending on anyone remembering the style guide, and starts being visible at the one moment somebody is reliably looking.

The surfaces outside the product — marketing, landing pages — are the harder half, and we will be straight about where that stands: standardizing copy across marketing, landing and product as one system is what we are building toward at globalize.now, not something you can switch on today. The mechanism is the same one described above, extended past the app boundary: if every surface references the approved string by key instead of restating it, changing a phrase is one decision rather than three.

Teams shipping with AI coding tools hit this earliest, which is why we write about it for developers and for people building with AI tools.

Does a style guide fix copy drift?

No — a style guide and a source of truth solve different problems, and teams routinely buy the first expecting the second.

A style guide describes what good copy looks like: tone, capitalisation, terminology, when to say “delete” and when to say “remove”. It is genuinely useful and every team should have one. What it cannot do is tell you that a string changed. It has no record of the previous wording and no hook into the moment of the change, so it can only be applied by a person who happens to be looking at the right screen.

Drift is a state problem, not a taste problem. The fix has to live where the state lives.

Drift starts the moment the same words exist in two places. globalize.now single-sources them in the repository you connect, and derives every language from that one copy.