Why does translation software charge per word?

Because the unit was borrowed, not chosen. Translators and agencies have billed per source word since long before software had a settings screen, and the platforms that grew up to serve localization departments adopted the pricing model their buyers already understood. It survives because it matches those vendors’ own costs and because it grows on its own as you grow — not because a word is a sensible way to measure what a translation platform does for a Save button.

Which does not make it wrong everywhere. It is a good model for translating documents and a poor one for translating software, and the difference between those two cases is arithmetic you can do in about a minute.

The four models#

Almost every platform in this category meters one of four things.

A segment is one string in the source language — Your changes have been saved is a single segment and five words. Translations are not counted at all under the last model, which is why target languages are free there and expensive under the first and third. The third is the one most easily misread, because it uses the word “string” for a quantity that includes every translation: see WebTranslateIt vs POEditor for what that does to a bill.

Where per-word pricing came from#

The translation industry had a pricing unit long before it had software. Agencies quoted per source word, freelancers invoiced per source word, and the Trados-era analysis report — with its fuzzy-match bands and weighted word counts — made the word the trade’s common currency. When translation management systems arrived, they were sold to the people already buying translation that way.

That is a genuine advantage for the vendor. If procurement already budgets eleven cents a word for German, a platform priced per word drops straight into a spreadsheet that exists. A platform priced per segment has to explain itself first, and having to explain your pricing is a real cost of doing business.

So the honest first answer to “why per word, in this day and age?” is that nobody re-derived it. It was inherited from a neighbouring business and never re-examined against what a TMS actually does.

Why it persists#

Four things keep it in place, in roughly descending order of how much they actually explain.

It tracks the vendor’s own costs. This is the most defensible reason and the one worth taking seriously. Crowdin runs a translator marketplace; Phrase sells professional services and machine translation; Transifex meters AI words. If you resell translation labour, your cost of goods really does scale with words. And as machine translation moves to large language models, the marginal cost becomes per-token inference — which is per-word wearing a different hat. Pricing the platform per word aligns revenue with cost. It aligns it with their cost structure, though, not with the work being done on your behalf.

It is the textbook subscription metric. “Price on something that grows as the customer grows” is orthodoxy for a reason. Words multiplied by languages grow on their own, which produces expansion revenue with no renegotiation and net revenue retention above 100% without selling anything new. That number is rewarded directly by investors. A metric that stops moving does not produce it.

It defers the real number past the decision. Not necessarily cynical, but the effect is consistent: a multiplying metric is hard to forecast when you are choosing, and the bill grows afterwards, when the cost of switching is highest. You evaluate at three languages and pay at twelve.

It looks cheap at the entry tier. A plan quoting sixty thousand hosted words sounds larger than one quoting five thousand segments, and the two are not remotely comparable — a segment is several words before language multiplication enters at all. Entry pricing on word-based plans is genuinely competitive, and that is where people compare.

When per-word is the right model#

It would be dishonest to present this as a pricing model with no proper use. Per-word is the right unit when:

• You are translating documents, not interfaces. Marketing pages, contracts, manuals, support articles. Long-form content where the length of the text really is the size of the job.
• You are buying the translation through the platform. If the vendor is sourcing and paying translators for you, you are buying something that is genuinely priced per word, and it would be strange to meter it any other way.
• Your content is short and your language count is low. More on this below, because it is the case people miss.

In all three, per-word is not a legacy artifact. It is the unit that matches the work.

Where it misfits software#

The mismatch is specific, and it is worth stating precisely rather than as a slogan.

The work does not scale with word count. What a TMS does to a string is store it, version it, index it into translation memory, validate its placeholders and plural forms, show it to a translator with context, and sync it back to your repository. Almost all of that is per string. A forty-word paragraph and a two-word button cost the platform about the same to manage. Metering the words charges you for a dimension the system barely spends anything on.

It bills you repeatedly for content you wrote once. Under the common definition — Crowdin states it plainly as the words to be translated multiplied by the number of target languages — shipping the same source file into twelve languages is twelve times the billable volume. You wrote the string once. The platform stores one source string and twelve translations, and charges you as though you had written twelve.

It taxes the behaviour the product exists to encourage. A localization platform’s entire purpose is to make shipping another language cheap. A model where each additional language is a line-item increase works directly against that. Teams ration languages to manage a bill, which is exactly the outcome the tool was bought to prevent.

Nobody designed that tax deliberately. It is what falls out of inheriting a unit from a business with different economics.

The number that decides it#

Here is the part worth doing yourself, because it settles the question in one multiplication.

Call your average words per segment w, and the number of target languages you ship L. A word-based plan bills roughly segments × w × L. A segment-based plan bills segments. Everything else is packaging.

So the ratio between the two models is w × L, and that single number tells you which side of the line you are on. Low means per-word is cheaper for you. High means per-segment is. Nothing else about your product matters nearly as much.

Worked both ways#

Two real product shapes, using published annual prices checked on 11 September 2026.

A button-heavy mobile app. 8,000 segments averaging two words — labels, menu items, toasts — shipped in three languages. That is 16,000 source words, so 48,000 hosted words. It fits inside Crowdin’s Pro plan at €534 a year. On our pricing, 8,000 segments needs Premium at €1,980 a year. Their model is better than three times cheaper, and we are the wrong choice for this product.

A documentation-heavy platform. 1,000 segments averaging forty words — help articles, onboarding copy, legal text — shipped in the same three languages. That is 40,000 source words, so 120,000 hosted words, which is past Crowdin’s Team allowance of 100,000 and into paid add-on volume above €1,603 a year. On our pricing, 1,000 segments sits inside Starter at €780 a year.

Same language count. Opposite answers. The only thing that changed was the average length of a string, and it moved the decision by a factor of several in both directions.

Now hold the content still and add languages instead. The documentation product at fifteen languages is 600,000 hosted words — Crowdin’s Team+ tier at €4,808 a year — while the segment count, and so our price, has not moved from €780. That is the asymmetry: one model has two multipliers and the other has none.

Which model favours you#

Most teams sit clearly in one column once they have done the multiplication. The mistake is doing it at today’s language count rather than the one you expect in two years, because that is the term of the decision you are actually making.

What to do with this#

Read the definition, not the number. “Hosted words” and “managed words” are vendor terms and they are not defined identically. Crowdin multiplies by target languages explicitly. Transifex counts source words translated into each language and deduplicates identical strings. Those differences are larger than the headline prices.

Model it at your two-year language count. The multiplier is the whole story, and it does not apply until you grow into it.

Price the machine translation separately. On metered platforms it is a second bill, and for a team planning to machine-translate and post-edit it can rival the subscription.

Then ignore pricing for a while and test the thing. Whichever model favours you, a platform that mangles your placeholders or loses a plural form will cost you more in engineering time than any of this. Our buyer’s guide covers what to check, and the head-to-head with Crowdin works the arithmetic through in more detail.

The short version#

Translation software charges per word because the translation industry always has, because it matches vendor costs when they also sell translation, and because a metric that multiplies is a good subscription business. Those are real reasons and two of them are legitimate.

It is the right unit for documents and the wrong one for software strings, where the platform’s work is per string and the multiplication by target language bills you again for source content you wrote once.

Work out your average words per segment, multiply by the languages you expect to ship, and let that decide. If the number is small, a word-based plan is cheaper and you should take it. If it is large, it is not close.