Skip to content
ZeroServer.tools

Base64 to Decimal Converter

Decode a Base64 string into its raw bytes, shown as a decimal array.

Drop a .txt file containing Base64, or click to browseReads the file as text and decodes its contents as Base64.
Decimal byte array (13 bytes)
Separator

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.

Related Converters tools

Private & free — this tool runs entirely in your browser.

IndieKitShip your Next.js startup in days.affiliate