We run gpt-5.4 (gpt-5.4-2026-03-05, Responses API) inside a UiPath agent that sends documents as PDF input_file (base64). Over the last few days we’ve seen failures that look like a recent change in PDF ingestion.
1. HTTP 400 “Bad Request” on PDFs with JPEG 2000 images
- Affected PDFs contain images with
/Filter /JPXDecode. These are standard 8-bit sRGB or greyscale JP2 images and decode fine in MuPDF, PDFium and Pillow/OpenJPEG.
- Seen with two different PDF producers (Power PDF Create, dbAutoTrack PDFWriter for .NET), on both image-only PDFs and PDFs with a text layer.
- A/B test: replacing only the JPX image streams with Flate (identical decoded pixels, nothing else changed) makes the same request succeed. Reproducible.
2. HTTP 400 on a PDF generated by ChatGPT itself (embedded C2PA manifest)
- A plain-text ReportLab PDF with no images. An OpenAI-signed C2PA manifest (“Content Credentials”,
application/c2pa) is attached to it as an embedded file (/AF + /EmbeddedFiles).
- A/B test: the same PDF, rewritten as a single revision with the manifest kept, fails with
You uploaded an invalid file. Please try again with a different file. The original revision without the embedded manifest succeeds.
- So the API rejects a PDF that ChatGPT itself produced and signed.
- Retried using gpt-5.6-sol: same issue.
3. Still present: pages with /Rotate are cropped
- Scanner PDFs (landscape MediaBox 842×595 +
/Rotate 270): the model only sees a 595×595 square. The top ~29% of the upright page, where often important data sits, is missing. Same issue as this thread: 1378921 (id - can’t include links here)
- Physically rotating the page image upright fixed it. Moving the rotation into the content stream (
/Rotate 0 + a cm matrix) did not, in our tests.
Questions
- Was PDF ingestion for
input_file changed recently? Are JPEG 2000 images and embedded files (including C2PA) unsupported now?
- Could the API return a descriptive error instead of a bare 400? The whole agent run fails without any hint of the cause.
- Any update on the
/Rotate fix?
As a workaround we’re adding a pre-processing step (probably a OCR model or: rotate pixels upright, re-encode JPX images, strip embedded files).
This exact failure mode is also happening to us. Our production org has ZDR enabled, and experiences the JPEG 2000 failure. Our dev org does not and continues to work with these kinds of PDFs.
Could it be related to recent Zero Data Retention changes?
Hi @jelle_1 and @vjaros3, thanks for the reports and for helping us narrow this down! We merged a fix for JPEG 2000 images in PDFs today, Oct 5, and are checking the rollout. If you’re still seeing failures, please share the x-request-id and UTC time so we can take a look. We’re checking C2PA separately.
@OpenAI_Support thanks. We’re still seeing the bare 400 You uploaded an invalid file today (Oct 6, ~08:45 UTC) on input_file PDFs (Responses API, base64) with gpt-6.1-sol. It also fails on gpt-6-sol.
-
JPEG 2000 still fails after your Oct 5 fix. A minimal PDF with one JPXDecode image returned a 400 at 2026-10-06 08:45:38Z.
-
There is a second trigger that isn’t JPEG 2000. A 37-page, 2.8MB business PDF with no JPXDecode, no embedded files and no rotated pages also fails (08:45:34Z). We believe the same file was accepted on Oct 5 around 11:49 UTC.
-
Our synthetic tests suggest a limit of about 50 placed images per PDF. A PDF with 50 images passes, and a PDF with 51 fails. This holds whether the images are on one page or spread across pages.
- The limit applies per file, not per request. Three 50-image PDFs in one request pass, but one 51-image PDF fails the whole request.
- Uploading via the Files API and then referencing the file ID gives the same 400.
Is there an intended image-count limit for PDF inputs, and was PDF ingestion changed after Oct 5? A descriptive error instead of the bare 400 would also help a lot.
@OpenAI_Support Thanks for the fix! We’re also still seeing it: today (Oct 6, ~16:44 UTC) a retry of a 1-page PDF containing a single JPEG 2000 image (Kofax Power PDF) still returned invalid_request_error (HTTP 400).
We can also confirm @maxsamne’s image-count observation. A 1-page Xerox scan with 18 images was accepted on Sep 29. A 6-page scan from the same scanner with 206 images (one background plus JBIG2 text masks per page) fails today.
Two questions:
- What is the rollout planning for the JPEG 2000 fix?
- Are you also looking at the
/Rotate issue? Scanned pages with /Rotate 90/270 still lose the top ~29% of the page (only a square reaches the model).
Thanks for the extra tests! That 50/51-image boundary matches a PDF scanning regression introduced on October 5, rather than an intended PDF input limit. The fix went live today. Can you retry the PDFs with more than 50 images?
The JPEG 2000 fix has merged, but its scanner update hasn’t gone live yet. C2PA and /Rotate cropping aren’t covered by these fixes. I don’t have a confirmed rollout date for the JPEG 2000 update yet.
I reported the /Rotate “square cropping” issue in April (topic 1378921). The bug has not been fixed yet is seem.
I reproduced it also in gpt-5.5, gpt-5.6-sol, gpt-6-sol and gpt-6.1-sol.
Is there an update specifically for this?
The rotate bug has been reproduced and reported - thank you!