Hi!
Reading a binary file from S3 returns corrupted data in a Workflow. The same action, on the same resource and the same object, returns correct data in an App.
The body is being decoded as UTF-8 before it is base64 encoded.
It broke 2026-08-25 first on our cloud account for content type: application/pdf Do you have any ideas why or will it happen in Apps too or any workarounds?
Thank you!
Summary
Reading a binary file from S3 via the 'Read file from S3' action returns UTF-8-mangled/corrupted data in a Workflow, even though the identical action on the same resource and object returns correct data in an App ā the body appears to be UTF-8-decoded before it is base64 encoded (reported on a Cloud account, starting 2026-08-25).
AI Response
This behavior stems from how the S3 resource handles binary content: for any object whose Content-Type is not on Retool's internal 'binary' allowlist, the resource UTF-8-decodes the body server-side and returns it as a plain string with IsBase64 false, at which point invalid byte sequences are irreversibly replaced with U+FFFD and the original bytes cannot be recovered. Because the outcome is driven by Content-Type sniffing, the read fidelity can differ between contexts and file types. As a workaround, ensure the S3 object is stored with a Content-Type that Retool treats as binary (for example, application/octet-stream) so the read returns an intact base64 body (IsBase64 true) that you can decode yourself. Retool staff have acknowledged this limitation and indicated that an opt-in binary/base64 handling option is the likely fix.
Sources
S3 resource needs a raw-bytes / streaming read
Details the exact root cause ā the S3 resource UTF-8-decodes bodies server-side unless the Content-Type is on Retool's binary allowlist, corrupting the bytes ā and includes a Retool staff acknowledgment that an opt-in binary handling option is being considered.
Corroborates that S3 read fidelity depends on the object's Content-Type, reinforcing the workaround of storing objects with a binary Content-Type.
The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a 
, 
, or 
. Or by marking this post as the "Solution"! Let us know if you have any feedback here. 
Hi @WittyRain
Thanks for reporting this issue! This looks to be due to a recent change on getting some DBConnectors (S3 included) from buffering to streaming via a feature flag (the rollout of the flag coincides with when you raised this community post). I went ahead and turned off the feature flag for your org. Can you let me know if the issue remains reproducible after this change?
Thanks so much!
Thank you Jeremy for looking into this!
it is working now both upload and download and both from our workflows and apps. Interestingly uploads created a the same kind of corrupted files between:
2026-09-01 18:58:42 - 2026-09-02 11:53:32 UTC
But the ones we uploaded later work fine again.
Hi @WittyRain
Happy to hear things are working! Iām unsure why there were still some intermittent behaviors post turning off the flag but I just want to confirm the behavior is no longer happening for PDF files at this stage?
Yes, seems all fine now.