Summary
On Retool Cloud, a Workflows REST block that fetches MP3 audio (audio/mpeg) from the ElevenLabs API started returning corrupted binary since a recent update — the raw bytes appear to be UTF-8 decoded before base64 encoding, replacing every non-UTF-8 byte with U+FFFD (EF BF BD / '77+9'), roughly doubling sizeBytes and destroying all valid MPEG frames.
AI Response
This matches a recently reported regression where some Retool DBConnectors were switched from buffering to streaming via a feature flag around 2026-08-25, which causes binary response bodies to be UTF-8 decoded (irreversibly corrupting non-UTF-8 bytes) before base64 encoding. Retool staff acknowledged this and resolved it for an affected org by turning the feature flag off, so reporting this thread with the org subdomain is the fastest path to having the flag disabled. In the meantime, a known workaround is to ensure binary payloads are treated as binary — e.g. serving/storing them with a Content-Type Retool treats as binary such as application/octet-stream — so the read returns an intact base64 body you can decode yourself.
Sources
S3 "Read file from S3" returns UTF-8-mangled binary in Workflows
A same-week report of the identical 'body is UTF-8 decoded before base64' binary corruption, where staff confirmed it was caused by a buffering-to-streaming feature-flag rollout (~2026-08-25) and fixed it by disabling the flag for the affected org.
A feature request that details the root cause — bodies being UTF-8 decoded server-side unless the Content-Type is on Retool's binary allowlist — and reinforces the workaround of using a binary Content-Type like application/octet-stream.
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. 