DeepL vs Google Translate, for product content, comes down to four things more than to raw quality: how well each engine keeps your terminology consistent, whether it can set formal or informal address, how it handles HTML descriptions and short attribute values, and what a full catalog costs per language. DeepL's API has a formality setting and does not bill HTML tags when tag handling is on. Google Cloud Translation covers more languages, adds glossaries and an LLM translation model in its Advanced edition, and is priced per character on a public rate card.
Published comparisons rarely settle the question for a store, because they test prose, not product titles with size ranges or a description with a spec table. So this guide compares the features that matter for catalogs, with limits and prices as they stood in August 2026, adds LLM translation as a third option, and ends with a fair test you can run on 50 of your own products in an afternoon.
Which engine fits which catalog
- Pick DeepL when you sell mainly in European languages, need a reliable switch between formal and informal address (Sie or du, vous or tu), and translate HTML descriptions where markup should not count toward billing.
- Pick Google Cloud Translation when you need many languages, including smaller markets, want glossaries that work across a whole project, or already run on Google Cloud and want one bill and one set of data terms.
- Pick an LLM-based workflow when you need the translation to follow rules a translation API cannot express: a tone of voice, marketplace title lengths, units per market, or fields that must stay untouched.
- Keep a human translator for legal and safety text, your top sellers and anything with wordplay or a slogan.
Why product data is harder to translate than prose
A blog post is one long text with plenty of context. A product record is twenty short fields with almost none. Take a 3-pack of merino crew socks, size 43 to 46, color navy:
Where product fields break in translation
| Title | "Merino Crew Socks 3-Pack, Navy, Size 43-46" | Keyword order and the size range must survive. |
|---|---|---|
| Attribute values | "Navy", "Crew", "Light" | Out of context, "Light" can become Licht (light as in lamp) or Leicht (lightweight) in German. |
| Option labels | The same value on hundreds of products, feeding your filters | If "Navy" becomes Marineblau on one product and Dunkelblau on another, the color filter splits in two. |
| Description | HTML with a list of features and a size table | Tags, rows and links must come back intact. |
| Meta title and description | Length limits that a longer target language easily breaks. | |
| Fields to leave alone | Brand, model number, GTIN, material codes | These stay as they are. |
Every engine below translates sentences well. The differences show up in how you control terminology, register, markup and those short values.
Glossaries: keeping "merino wool" identical across 4,000 listings
A glossary tells the engine how to translate a specific term, or to leave it as is. For catalogs it is the single most useful feature, because it keeps brand terms, product types and filter values consistent.
- DeepL: glossaries are applied per request with a glossary ID, and the translate endpoint requires you to set the source language when you use one.
- Google Cloud Translation: glossaries are a feature of the Advanced edition. Since November 2024 they also work with the Translation LLM model, with a contextual option that fits the term into the sentence (Google's release notes).
- LLM translation: you pass the glossary in the prompt or as structured data. That handles inflection better than a find-and-replace, but the model can still ignore a term, so check the output against the glossary afterwards.
A glossary is only as good as its entries. Start with your top 100 terms: product types, materials, filter values and the brand names that must stay in the source language. Add a term each time a reviewer corrects the same word twice.
Formal or informal address: du or Sie, tu or vous, je or u
Most stores pick one register per market and stick to it. A German shop that says du on the homepage and Sie in product descriptions reads like two companies.
DeepL's API has a formality parameter with the values default, more, less, prefer_more and prefer_less. It is only available for certain target languages, and a request with more or less fails for a language without formality support, which is why the prefer_ options exist. If you translate into many languages in one job, use prefer_less or prefer_more.
Google's NMT model has no formality parameter, and the release notes do not list one. With Adaptive Translation you can pass up to five reference sentence pairs per request (added in May 2024), and those examples steer tone and register. With an LLM, you state the register in the instructions, which works for any language the model handles well.
Spec tables, tags and one-word attribute values
Product descriptions usually arrive as HTML: paragraphs, bullet lists, a size or spec table, sometimes a link. All three options can keep markup, but they behave differently:
- DeepL: set tag_handling to html on the translate endpoint and the API translates the text while keeping the HTML structure. With tag handling enabled, the tags are not billed, according to DeepL's character usage guide.
- Google: in the Advanced edition the input can be plain text or HTML, and tags are kept while only the text between them is translated. The Translation LLM model has accepted HTML input since July 2024.
- LLM: markup survives most of the time, which is not good enough at catalog scale. A model can drop a table row or merge two list items. Compare tag counts between source and translation automatically and resend any field where they differ.
Short attribute values need context. DeepL has a context parameter: text that influences the translation but is not translated or billed. Sending "Light" with the context "weight class of a hiking jacket" gets you Leicht instead of Licht. With Google NMT, the closest workaround is to translate the value together with its attribute name and split the result again, which is fragile. An LLM can receive the whole product record as context, which is its main advantage for attributes.
API pricing and limits as of August 2026
Google Cloud Translation
Google Cloud Translation prices, August 2026
| NMT (Basic and Advanced) | $20 | The first 500,000 characters a month are free, applied as a $10 monthly credit (Google Cloud pricing). | |
|---|---|---|---|
| Translation LLM | $10 | $10 | Both counted per target language. |
| Adaptive Translation | $25 | $25 |
DeepL API
- Plans: by mid-2026 DeepL sold new API subscriptions as Developer, Growth and Enterprise (DeepL pricing page). Developer is free and comes with a one-time credit of 1 million characters that does not renew. Growth charges a monthly or annual base price plus usage, with a set number of characters included per period, and Enterprise is priced on request. Check DeepL's rate card for the Growth price in your currency.
- Billing: source characters, counted in Unicode code points. Text in the context parameter is not billed, and neither are tags when tag handling is on.
- Request size: 128 KiB per request, with many texts allowed per request.
What a 4,000-product catalog costs per engine
Assume 4,000 products with about 1,800 characters each across title, description, attributes and meta fields. That is 7.2 million characters per language, or 21.6 million for German, French and Dutch.
- Google NMT: 21.6 million minus the free 500,000 is 21.1 million characters, at $20 per million: about $422.
- Google Translation LLM: $216 for input plus about $216 for output if the translations are roughly as long as the source: about $432. German output is often longer, so expect a little more.
- DeepL: depends on your Growth plan's included characters and overage rate. Because tags in HTML descriptions are not billed, a description-heavy catalog counts fewer characters than with Google.
The first translation is not the real cost. Every time a supplier updates 600 descriptions, those products need translating again. Only send fields whose source text changed, and keep a translation memory so unchanged sentences are not paid for twice.
Data privacy: where your catalog text goes
Unreleased products, purchase prices in internal notes and supplier texts under NDA all pass through a translation engine. The terms differ by product and by plan:
- Google Cloud Translation API: Google states that text is held briefly in memory to perform the translation and that it does not use the content you send to train its translation features.
- DeepL paid plans: the DeepL pricing page says subscriber texts are stored only as long as technically needed to provide the service, deleted afterward and never used to train DeepL's models.
- Free web translators: consumer translation sites run on different terms than paid APIs, and those terms can allow pasted text to be stored and used to improve the models. Read the privacy policy, and keep confidential catalog data out of free tools.
- LLM APIs: check the provider's API terms for training use and retention, and whether you can choose an EU data region.
LLM translation as the third option
Large language models translate well, and for catalogs their strength is instructions. You can tell a model to keep the brand and model number untouched, write in informal German, keep a marketplace title under 75 characters and return the result as JSON with the same field names. A translation API cannot take that kind of brief.
The weaknesses are the mirror image. Output can vary between runs, a model may shorten or embellish a description, and it can lose markup. At catalog scale, an LLM workflow needs guardrails: a fixed glossary and register per language, structured output per field, automatic checks for tag counts, numbers and units, and a sample review by a native speaker.
WISEPIM uses its own LLM-based translation, not DeepL or Google Translate. Its AI translation is 95%+ accurate and works per field, with a translation dictionary, a strict mode for literal translation, tone settings and checks that tables and lists survive the translation.
A fair test: 50 products, three engines, blind review
You can settle the choice with your own data in a few hours. A test of 50 products into three languages is about 270,000 characters, which fits in Google's free monthly allowance and DeepL's Developer allowance.
Blind test: 50 products, three engines
Record the results as one line per engine and language: error points per 1,000 words, glossary hit rate, broken markup count, edit minutes per product and cost per 1,000 products. The winner is often different per language, which is an argument for a workflow that lets you choose.
Where human translators still earn their fee in a catalog
The choice is rarely all or nothing. Machine translation with review is the practical default for the long tail, where hundreds of similar products share the same structure. Human translation or careful editing pays off for your 50 best sellers, category intro texts, slogans, safety warnings and legal text such as return conditions.
Translation is also only part of entering a market. Keywords differ per language, as the multilingual SEO playbook explains, and prices, units and regulations differ per country, as covered in the guide to international ecommerce. For the process side, see product content translation management.
Running product translation inside the catalog
Whichever engine you choose, translation works best close to the product data, where fields, glossary and review live together. In WISEPIM you translate products with AI per field into the languages you sell in, manage terms in the translation dictionary and push the result to connected stores. Tackerplein used it to get German translations in 6 weeks instead of the 4 to 6 months an agency would have taken, as described in the Tackerplein case. If German is your next market, the page on translating products to German covers the specifics.
