API reference for translating text with the DeepL API.
translate
, which is described below.
To learn more about context in DeepL API translations, we recommend this article.
For more detail about request body parameters, see the Request Body Descriptions section further down on the page.
We also provide a spec that is auto-generated from DeepL’s OpenAPI file. You can find it here.
https://api.deepl.com
. If you’re an API Free user, remember to update your requests to use https://api-free.deepl.com
instead.context
parameter makes it possible to include additional context that can influence a translation but is not translated itself. This additional context can potentially improve translation quality when translating short, low-context source texts such as product names on an e-commerce website, article headlines on a news website, or UI elements.For example:
For best results, we recommend sending a few complete sentences of context in the same language as the source text. There is no size limit for the context
parameter itself, but the request body size limit of 128 KiB still applies to all text translation requests.
If you send a request with multiple text
parameters, the context
parameter will be applied to each one.
Characters included in the context
parameter will not be counted toward billing (i.e., there is no additional cost for using the context
parameter, and only characters sent in the text
parameter(s) will be counted toward billing for text translation even when the context
parameter is included in a request).
quality_optimized
value is supported only in the Pro v2 API at this time (https://api.deepl.com/v2/translate
).Possible values are:
latency_optimized
(uses lower latency “classic” translation models, which support all language pairs; default value)quality_optimized
(uses higher latency, improved quality “next-gen” translation models, which support only a subset of language pairs; if a language pair that is not supported by next-gen models is included in the request, it will fail. Consider using prefer_quality_optimized
instead.)prefer_quality_optimized
(prioritizes use of higher latency, improved quality “next-gen” translation models, which support only a subset of DeepL languages; if a request includes a language pair not supported by next-gen models, the request will fall back to latency_optimized
classic models)Requests with the model_type
parameter will include an additional response field model_type_used
to specify whether DeepL’s latency_optimized
or quality_optimized
model was used for translation.
Note: In the future, if DeepL’s quality optimized models achieve language pair and latency performance parity with classic models, it’s possible that next-gen models will be used regardless of the value passed in the model_type
parameter.
Language pairs supported by DeepL’s next-gen models are documented below.
tag_handling
is not set to html
, the default value is 1
, meaning the engine splits on punctuation and on newlines.For text translations where tag_handling=html
, the default value is nonewlines
, meaning the engine splits on punctuation only, ignoring newlines.
The use of nonewlines
as the default value for text translations where tag_handling=html
is new behavior that was implemented in November 2022, when HTML handling was moved out of beta.
Possible values are:
0
- no splitting at all; whole input is treated as one sentence1
(default when tag_handling
is not set to html
) - splits on punctuation and on newlinesnonewlines
(default when tag_handling=html
) - splits on punctuation only, ignoring newlinesFor applications that send one sentence per text parameter, we recommend setting split_sentences
to 0
, in order to prevent the engine from splitting the sentence unintentionally.
Please note that newlines will split sentences when split_sentences=1
. We recommend cleaning files so they don’t contain breaking sentences or setting the parameter split_sentences
to nonewlines
.
Please note that this value will be ignored when using next-gen models (model_type_used=quality_optimized
) and a value of:
0
will be used if tag_handling
is not enablednonewlines
will be used if tag_handling
is enabled…as these settings yield the best quality.
The formatting aspects affected by this setting include:
DE
(German), FR
(French), IT
(Italian), ES
(Spanish), NL
(Dutch), PL
(Polish), PT-BR
and PT-PT
(Portuguese), JA
(Japanese), and RU
(Russian). Learn more about the plain/polite feature for Japanese here.Setting this parameter with a target language that does not support formality will fail, unless one of the prefer_…
options are used. Possible options are:
default
(default)more
- for a more formal languageless
- for a more informal languageprefer_more
- for a more formal language if available, otherwise fallback to default formalityprefer_less
- for a more informal language if available, otherwise fallback to default formalitysource_lang
parameter to be set and the language pair of the glossary has to match the language pair of the request.true
, the response will include an additional key-value pair with the key billed_characters
and a value that is an integer showing the number of characters from the request that will be counted by DeepL for billing purposes.For example: “billed_characters”: 42
billed_characters
in the API response by default, at which point it will be necessary to set show_billed_characters
to false
in order for an API response not to include billed_characters
. We will notify users in advance of making this change.For requests sent as URL-encoded forms, boolean values should be specified as “1” or “0”.xml
: Enable XML tag handling; see XML handling.html
: Enable HTML tag handling; see HTML handling.outline_detection
parameter to false
and selecting the tags that should be considered structure tags. This will split sentences using the splitting_tags
parameter.In the example below, we achieve the same results as the automatic engine by disabling automatic detection with outline_detection=false
and setting the parameters manually to tag_handling=xml
, split_sentences=nonewlines
, and splitting_tags=par,title
.
While this approach is slightly more complicated, it allows for greater control over the structure of the translation output.
quality_optimized
value for the model_type
parameter is currently supported only in the Pro v2 API (https://api.deepl.com/v2/translate
).model_type
parameter when the quality_optimized
or prefer_quality_optimized
values are sent in a request depends on language pairs that are supported by DeepL’s next-gen translation models.
Currently, all source and target languages are supported by next-gen models. In the future, if we add language pairs that are not supported by next-gen models, a request will fail (if model_type
is set to quality_optimized
) or fall back to classic models (if model_type
is set to prefer_quality_optimized
) if the chosen language pair does not support next-gen models.
The /languages
endpoint has not yet been updated to include information about model_type
support, but we expect to make such a change in the future.
https://api.deepl.com
. If you’re an API Free user, remember to update your requests to use https://api-free.deepl.com
instead.https://api.deepl.com
. If you’re an API Free user, remember to update your requests to use https://api-free.deepl.com
instead.