S3 "Read file from S3" returns UTF-8-mangled binary in Workflows

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

:bookmark: 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.
:bookmark: Downloading a excel file from s3 broken depending on contentType?
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 :heart:, :+1:, or :-1:. Or by marking this post as the "Solution"! Let us know if you have any feedback here. :rocket: