Power Automate returns image content as Base64-encoded text inside JSON responses, data URL fields, and attachment properties, and the fastest way to convert that string into a real, viewable file is to paste it into the Base64 to Image Converter, a browser tool that decodes strict RFC 4648 Base64 or a data URL with an explicit ;base64 marker into a validated PNG, JPEG, GIF, or WebP image entirely in your local tab. The tool accepts up to 8,000,000 UTF-16 code units of input, refuses to produce anything larger than 5,242,880 decoded bytes (5 MiB), and requires the browser to actually decode the bytes and report positive dimensions before showing a preview or offering a download. Because the converter does not trust declared MIME types and detects the real format from the file signature, it also handles the common Power Automate case where an HTTP response or connector advertises image/jpeg but actually contains PNG, GIF, or WebP bytes. Nothing leaves your machine during this round trip, which matters when the image contains customer data, signed documents, or anything you would not upload to a random web service.
That last point is the practical reason Power Automate users hit this question so often. The platform shuttles image data as Base64 because that representation is text-safe, transportable through JSON, and survives every HTTP and SMTP hop without binary corruption. The trade-off is that you, the human inspecting the result, cannot look at a Base64 string and see whether the payload is a 4,000-pixel-wide PNG or a 640-pixel-wide WebP. You need a decoder that not only unwinds the encoding but also tells you the format, the dimensions, and the byte size, and that gives you a real file at the end of it.

Why Power Automate Hands You Images as Base64
Almost every modern Microsoft connector and every HTTP action that returns a picture does so by encoding the binary as a Base64 string. SharePoint file contents, Outlook message attachments fetched through the Office 365 connector, the response body of an HTTP action, custom connectors built from OpenAPI definitions, and Power Apps component framework data sources all converge on the same shape: a JSON field such as contentBytes, body, fileContent, or data that contains a long alphanumeric string. That string is the image, but you cannot paste it into Word, attach it to an email, or open it in Photos as it stands.
Power Automate's native base64ToBinary() expression does half the work by handing you back a binary blob, but it does not tell you whether the bytes form a PNG, JPEG, GIF, or WebP, and it does not give you a file you can drag onto your desktop. The cleanest debug path is to copy the original Base64 string out of the run history, paste it into a converter that inspects the signature, and confirm the actual format before you wire the binary into the next action.
The Two Shapes Power Automate Base64 Can Take
Power Automate payloads show up in two forms, and the converter handles both. Knowing which one you have saves you from staring at a "malformed data URL" error message.
| Shape in Power Automate | Example fragment | What the converter does |
|---|---|---|
| Plain Base64 | iVBORw0KGgoAAAANSUhEUgAA... | Decodes directly, infers format from the byte signature, picks an extension from that signature. |
| Data URL with ;base64 | data:image/png;base64,iVBORw0KGgo... | Strips the prefix, validates the type/subtype parameter, requires the comma and the ;base64 token, then decodes the rest. |
The strict parser only accepts canonical RFC 4648 Base64. That means standard alphabet characters, a length divisible by four, padding only at the end, and zero unused pad bits. Whitespace, line wrapping, URL-safe minus and underscore characters, and missing padding all fail. Power Automate's base64() and base64ToString() functions do not always emit canonical output, so a string that round-trips through a Compose action can quietly gain spaces or lose padding. If the converter rejects the input, that is your cue to clean the string in Power Automate first with a replace() expression, or to use a dedicated browser decoding walkthrough as a sanity check before you spend another hour chasing the flow.
Convert Base64 to Image from a Power Automate Flow
Use this procedure when a Power Automate run gives you a Base64 image and you want a real file to open, attach, or hand off to a colleague for review.
- In the Power Automate run history, open the failing or interesting action, expand its outputs, and locate the field that contains the Base64 string. Common keys are body, contentBytes, $content, and fileContent.
- Copy the value to your clipboard. If the value is wrapped in JSON quotes, include the quotes only if you plan to use a data URL form; otherwise, copy the alphanumeric payload alone.
- Open the Base64 to Image Converter in a new browser tab. The whole conversion runs locally, so no data is sent to a server.
- Paste the Base64 string into the input field. If the string already starts with data:image/... and includes ;base64,, the parser will accept it as a data URL. If the string is plain Base64 with no prefix, that is also fine.
- Click the Convert to image action. The decoder checks the alphabet, recomputes the expected output length, decodes the bytes, and runs a structural preflight against the PNG, JPEG, GIF, or WebP specification.
- Confirm the detected format, the decoded dimensions, the byte size, and the preview. If the preview looks wrong, the declared MIME type in the original payload does not match the actual bytes, and the converter is showing you the real format instead of the advertised one.
- Click the download link to save the original decoded bytes. The extension on the downloaded file is chosen from the verified file signature, so a payload advertised as image/jpeg that turns out to be a PNG will download as file.png rather than file.jpg.
If the conversion fails with an explicit error, the message tells you which rule was violated. Empty input, illegal whitespace, malformed data URL, invalid alphabet or padding, decoded data over the byte limit, an unrecognized or structurally incomplete container, a corrupt browser-undecodable image, and excessive decoded dimensions are all reported as separate error classes. The tool never silently rewrites the input, so a failure points directly at a problem in the source string.
What Happens When the Declared MIME Type Is Wrong
Power Automate connectors are not always accurate about what they are returning. A connector that says it is sending image/jpeg can ship PNG, GIF, or WebP bytes by accident, especially when the upstream service has been refactored or a custom connector is doing its own encoding. Saving those bytes with a .jpg extension produces a file that refuses to open in most viewers and forces you to debug from a fresh download.
The converter treats the declared MIME as untrusted metadata. It detects the real format from the eight-byte PNG signature, the JPEG start-of-image marker, the GIF87a or GIF89a header, or the RIFF/WEBP container, and it uses that detection for both the preview and the download extension. The declared type/subtype is displayed so you can see the mismatch, but it never wins over the actual bytes. For Power Automate users, this means a single paste can resolve a "file will not open" mystery without writing any inspection code.
Limits and Edge Cases to Watch For
Before you paste, it helps to know the exact boundary conditions the converter enforces. The table below summarizes the values you can rely on, and the document specification each one is drawn from.
| Constraint | Value | Why it exists |
|---|---|---|
| Input size (UTF-16 code units) | 8,000,000 | Bounds the parser and avoids runaway string handling. |
| Decoded byte limit | 5,242,880 (5 MiB) | Prevents the tool from allocating huge arrays in the browser tab. |
| Max width or height | 20,000 pixels | Protects browser memory because small encoded files can expand to large pixel surfaces. |
| Max total pixel area | 40,000,000 pixels | Same protection for very wide or very tall images. |
| Accepted formats | PNG, JPEG, GIF, WebP | Structural preflight is implemented for these four; everything else is rejected up front. |
If a payload is bigger than the decoded byte limit, the converter rejects it before allocation rather than truncating, so you never receive a partial file. If a payload passes the byte check but the resulting image is too large in either dimension, the tool reports "excessive decoded dimensions" instead of letting the browser hang. Power Automate users occasionally hit the byte ceiling with screenshots, scanned PDFs turned into image streams, or long bursts of high-resolution photos, and the safest response is to compress the source before re-encoding.
What to Do Once You Have the Image File
The downloaded file contains the exact decoded bytes from your Base64 string, so a PNG keeps its alpha channel, a JPEG keeps its compression, an animated GIF keeps its frames, and a WebP keeps its transparency. The browser preview is only constrained for page layout; the saved file is not redrawn through a canvas and is not recompressed. That means the file is faithful to the source, but it is not optimized, and you may want to shrink it before sharing.
For a smaller file with the same dimensions, run the downloaded image through the Image Compressor, which keeps everything local. For a different resolution, use the Image Resizer. If you want to inspect EXIF or camera metadata that may be embedded in a JPEG, the EXIF Viewer reads the fields without uploading the photo. If the original Base64 string came from the opposite direction, meaning you have a file and need to encode it back into a string for a Power Automate expression, the matching Image to Base64 Converter handles the reverse trip with the same signature-based format detection.
For most Power Automate debugging sessions the loop is short: copy the Base64 from a run, paste it into the converter, confirm the actual format, and decide whether the next action in your flow needs to be adjusted or whether the upstream API is the real problem. Because the conversion is local, you can do this on a confidential screenshot, a customer-uploaded image, or a signed document without moving the bytes off the device.