Decode Base64 image info

It performs the work locally, without fetching a URL, uploading an image, guessing a file extension, or inspecting remote content. Strict validation catches missing markers, invalid characters, incorrect padding, noncanonical unused bits, and non-image media types, making the result suitable for form validation, storage planning, logging, and automated ingestion checks.

Read the information already carried by a data URI

A Base64 image data URI combines metadata and encoded bytes in one string. Its header identifies the media type, while the payload represents the original binary data in groups of printable characters. This capability separates those parts only after confirming that the whole value follows the expected structure. A successful result contains `mime_type`, such as `image/png`, and `byte_length`, the exact number of decoded bytes. It does not estimate size from character count alone: it accounts for the final Base64 padding characters, which indicate whether the last group represents one, two, or three bytes. The tool deliberately reports the declared MIME type rather than claiming to recognize an image from its binary signature. That distinction matters when you are validating an API request or examining generated markup. You learn exactly what the data URI says and how large its decoded payload is, without silently changing, normalizing, or re-encoding the supplied value.

Understand what strict validation rejects

The accepted form is a complete `data:image/type;base64,payload` value. The media type must begin with `image/`, the Base64 marker must be present, and a single comma must separate the header from the payload. The payload must use the standard Base64 alphabet, have a length divisible by four, and place padding only at the end. Validation also checks unused bits in the final encoded group. This catches noncanonical strings that permissive decoders may accept even though multiple spellings could represent the same bytes. Empty payloads, embedded whitespace, URL-safe Base64 characters, extra metadata parameters, missing padding, and ordinary web URLs are rejected as malformed input. These constraints provide a predictable contract for automation. If your source produces a raw Base64 fragment rather than a complete data URI, add the correct image MIME header before calling the capability. If it produces Base64url, convert it to canonical standard Base64 first instead of relying on decoder tolerance.

Use byte length without exposing or transferring the image

Knowing decoded byte length before storing or forwarding an image is useful in upload gates, database checks, message-size limits, and observability pipelines. You can reject an oversized inline asset before another service parses it, record consistent size metadata alongside HTML or JSON, or compare the overhead of inline images with linked resources. The calculation is deterministic and needs no external network access. It scans the supplied string, validates its syntax, and derives the byte count from complete Base64 groups and terminal padding. No URL is followed, no remote MIME type is consulted, and no timestamp or random identifier appears in the output. The browser runner and API therefore return the same two fields for the same input. This capability does not verify that the decoded bytes truly match the declared image format, calculate image dimensions, repair corrupted files, or return the decoded binary. Use it when structural validation and exact payload size are the questions; use a format-aware image inspector when content verification is required.