Document Translation - PDF document is failed to translate

Mahesh Addagulla 0 Reputation points
2026-08-04T12:00:07.15+00:00

Hi,

Hello Team,

I have created an Azure AI Cognitive Services resource and a project in Microsoft Foundry. I am currently testing the Document Translation API with various file formats, including:

  • TXT
  • DOCX
  • JPG
  • PPTX
  • PDF

I am using API version 2026-03-01 for all requests.

The translation service works successfully for TXT, DOCX, JPG, and PPTX files. However, translations consistently fail when processing PDF files. The same API endpoint and configuration are being used, with only the input document format changed.

Could you please help verify whether PDF translation is supported with API version 2026-03-01, or if there are any known limitations, prerequisites, or additional configurations required for PDF documents?

Any guidance on troubleshooting this issue would be greatly appreciated.

Thank you.

Additional Information

  • API Version: 2026-03-01
  • Service: Azure AI Translator / Document Translation
  • Supported formats tested successfully: TXT, DOCX, JPG, PPTX
  • Issue: PDF translation requests fail while other formats succeed
  • Error message: 
"error":{"code":"InvalidRequest","message":"The format parameter is not valid.","target":"ContentType",
"innerError":{"code":"InvalidFormat","message":"The format parameter is not valid."}}}

Here is my curl:

curl  -i --cacert test_ca.pem --cert test.pem --request POST "https://mtls-apim-service/test/doctranslate/document:translate?targetLanguage=te&api-version=2026-03-01" \
  --header 'ocp-apim-subscription-key: 1234' \
  --form 'document=@demo.pdf' \
  --output translated-document-te.pdf

I have seen similar reports in other channels but Is there any update on the issue? Does it addressed in any other api versions?

Thank you.

Azure Translator in Foundry Tools

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-08-04T12:00:31.4466667+00:00

    PDF is supported for Document Translation, including API version families documented for Document Translation. For batch translation, pdf is a supported document format. For synchronous document translation, the service supports translating a single file and returning the translated file in the response.

    The error shown points to the uploaded document format/content type being rejected:

    "target":"ContentType" with InvalidFormat

    For PDF-specific checks:

    1. Confirm the file is a real PDF and not encrypted or password-protected. Password-protected or encrypted documents aren’t supported.
    2. If the PDF is scanned, PDF translation is supported, but output quality and layout retention can vary. Native PDFs provide the best results.
    3. If the PDF contains both digital and scanned elements, only the digital portions are translated. To translate the full document, convert it into a fully scanned format before submission.
    4. If the document has visible watermarks or seals, translation can fail or be partial.
    5. If the PDF is very large or complex, split it into smaller sections and test again.

    The cURL example for synchronous document translation shows the document part should include an explicit content type. For example, the documented pattern is:

    -F "document=@{path-to-your-document-with-file-extension};type={ContentType}/{file-extension}"

    For a PDF request, the first thing to verify is that the multipart form part for document includes the correct PDF content type instead of sending only @demo.pdf.

    Also verify the endpoint type being called. The documented synchronous API for document translation is the Document Translation endpoint pattern:

    POST .../translator/document:translate?...

    If the issue persists, use the supported-formats API to confirm what the service reports for the endpoint and API version being used. The supported formats method returns the list of supported document formats and requires the custom domain endpoint for Document Translation.

    Because other file types succeed and the failure is specifically ContentType/InvalidFormat, the most likely issue in this request is the PDF upload format metadata rather than PDF support being unavailable.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Thanmayi Godithi 11,825 Reputation points Microsoft External Staff Moderator
    2026-08-04T13:38:01.1933333+00:00

    Hi Mahesh Addagulla ,

    Thank you for providing the details.

    Based on the current Azure Translator Document Translation documentation and the endpoint used in your request, the behavior appears to be related to the translation method being used rather than a service defect. The Document Translation API supports two workflows: synchronous single-file translation and asynchronous batch translation, and the supported document formats differ between them.

    Your request is calling the synchronous endpoint and it indicates that the uploaded document format is being rejected by the synchronous translation operation.

    In API version 2026-03-01, Microsoft documentation specifically introduces PDF** translation with Azure Document Intelligence (batch **only) to preserve document layout and structure. PDF translation is documented under the asynchronous batch translation workflow, which requires Azure Blob Storage containers for source and translated documents. [learn.microsoft.com].

    To translate PDF files, please use the asynchronous batch translation workflow:

    1. Upload the PDF to a source Blob Storage container.
    2. Submit a batch translation job.
    3. Poll the job status.
    4. Download the translated PDF from the target container.

    This workflow is the documented approach for PDF translation in the current release.

    A couple of additional points:

    • The synchronous API examples show providing an explicit MIME type for the uploaded document part. While this is recommended, it is unlikely to resolve the PDF issue if the format itself is not supported by the synchronous operation.
    • Since you mentioned that JPG files translate successfully, could you confirm whether the translated image was returned successfully through the same document:translate endpoint? Image translation capabilities are documented in recent Document Translation releases, so understanding that result may help validate the exact endpoint behavior being observed.
    • If you're using an APIM endpoint (https://mtls-apim-service/...), it would also be useful to test directly against the Translator resource custom domain endpoint to rule out any gateway-specific request processing behavior.

    I hope this helps clarify the behavior. If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.