Base64 to Decimal Converter
Decode a Base64 string into its raw bytes, shown as a decimal array.
How Base64 to decimal conversion works
Base64 represents binary data using 64 printable characters, packing three raw bytes into four Base64 characters (6 bits each). To reverse it, this tool decodes the string back into its original bytes with the browser's built-in atob() function, then reads each byte's numeric value (0–255) to build a decimal array — for example, decoding SGk= (the text "Hi") yields the bytes 72, 105. Both standard Base64 and URL-safe Base64 (using - and _ instead of + and /) are accepted, along with missing padding. Everything runs locally in your browser — nothing is uploaded anywhere.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Turning a Base64 blob into byte values you can inspect one at a time.
- Checking the raw bytes behind an encoded field during debugging.
- Producing a decimal byte array for a test fixture from an encoded value.
- Confirming a decoded length matches what a protocol specifies.
- Comparing two encoded values byte by byte.
Frequently Asked Questions
- What does decoding to decimal give me?
- The raw byte values the Base64 was carrying — one number per byte, 0 to 255. `SGk=` decodes to 72, 105, the ASCII codes for H and i. It is the view you want when the payload is binary rather than text and you need to inspect it byte by byte.
- Does it accept URL-safe Base64?
- Yes. `-` and `_` are translated back to `+` and `/` before decoding and missing padding is restored, so a JWT segment or a URL parameter decodes without editing. Those two substitutions are the entire difference between the standard alphabet and RFC 4648 §5's URL-safe one.
- Why is padding added back automatically?
- Because many encoders strip it — JWTs mandate its removal — while `atob` requires the length to be a multiple of four. Re-adding `=` until it is restores what was dropped without changing the data, since padding carries no information of its own.
- Why are the numbers not the character codes I expected?
- Probably because the original text was not ASCII. Base64 encodes BYTES, and a non-ASCII character is several UTF-8 bytes — `é` is 195, 169, not a single 233. The decimal output is faithful to the bytes; it is the assumption of one byte per character that breaks.
- What if the string is not valid Base64?
- `atob` throws and the error is reported rather than swallowed. The usual causes are a stray character from a copy-paste, a `data:image/png;base64,` prefix left attached, or an already-decoded string. Whitespace and line breaks are stripped first, so wrapped Base64 from an email or PEM file is fine.
Common errors and gotchas
- Reading the decimal values as signed bytes, so anything above 127 appears negative.
- Losing padding in transit, after which some decoders refuse the string entirely.
- Reading the byte values as character codes, which only coincides for ASCII.
- Assuming the decoded bytes are text at all, when Base64 carries anything.
- Leaving a `data:` prefix in place when the decoder expects raw Base64.