About

Base64 encoding represents binary data as ASCII text using a 64-character alphabet (A - Z, a - z, 0 - 9, +, /). Every 4 Base64 characters encode exactly 3 raw bytes. Misinterpreting the byte order or signedness when converting those bytes to integers is a common source of bugs in protocol implementations, firmware uploads, and cryptographic key parsing. This tool decodes a Base64 string into its constituent bytes, then interprets them as integer sequences under the exact type width and endianness you specify. It supports unsigned and signed variants at 8, 16, and 32-bit widths. Padding (=) is handled per RFC 4648.

Limitations: this tool operates on standard Base64 (RFC 4648 §4). Base64url variants (- and _ instead of + and /) are auto-detected and normalized. Inputs that do not decode to a byte count divisible by the chosen type width will process only complete groups and flag the remainder. Float interpretation (IEEE 754) is outside scope.

Formulas

Base64 decoding maps each group of 4 encoded characters back to 3 raw bytes. The total decoded byte count is:

B = 34 × L − P

where B = decoded byte count, L = length of Base64 string (excluding whitespace), P = number of padding = characters (0, 1, or 2).

For multi-byte integer interpretation, bytes are grouped into chunks of width W (1, 2, or 4). The number of complete integers is:

N = floor(BW)

For unsigned big-endian reconstruction of a W-byte value from bytes b₀, b₁, …, b_W−1:

v = W−1∑i=0 b_i × 256^W−1−i

For little-endian, the exponent is simply i instead of W−1−i. For signed (two's complement) conversion:

{

v if v < 2^W×8−1v − 2^W×8 otherwise

where v = unsigned interpretation, W = byte width, and b_i = the i-th byte in the group.

Reference Data

Integer Type	Width	Range Min	Range Max	Bytes per Value	Endian Relevant
uint8	8 bit	0	255	1	No
int8	8 bit	−128	127	1	No
uint16	16 bit	0	65535	2	Yes
int16	16 bit	−32768	32767	2	Yes
uint32	32 bit	0	4294967295	4	Yes
int32	32 bit	−2147483648	2147483647	4	Yes
Common Base64 Reference Strings
`AA==`	Decodes to		1 byte: [0]
`/w==`	Decodes to		1 byte: [255]
`AQI=`	Decodes to		2 bytes: [1, 2]
`AQID`	Decodes to		3 bytes: [1, 2, 3]
`AAAAAQ==`	uint32 BE		0, then incomplete (only 1 trailing byte)
`SGVsbG8=`	ASCII		[72, 101, 108, 108, 111] = "Hello"
`gIA=`	int8		[−128, −128]
`//8=`	uint16 BE		[65535]
`/////w==`	uint32 BE		[4294967295]
`AAAAAAAAAAE=`	uint32 BE		[0, 0] + 1 trailing byte

Frequently Asked Questions

The converter processes only complete integer groups. For example, if your Base64 decodes to 7 bytes and you select uint32 (4 bytes per value), you get 1 integer from the first 4 bytes. The remaining 3 bytes are reported as trailing bytes and displayed separately as uint8 values so no data is silently discarded.

Big-endian (BE, network byte order) places the most significant byte first. Little-endian (LE, x86/ARM default) places the least significant byte first. For the bytes [0x00, 0x01], uint16 BE gives 1 while uint16 LE gives 256. If your data originates from network protocols (TCP/IP, DNS), use BE. If from x86 memory dumps or most file formats on modern PCs, use LE. When unsure, try both and check which produces values in the expected range.

Yes. The converter auto-detects Base64url characters (- and _ per RFC 4648 §5) and normalizes them to standard Base64 (+ and /) before decoding. No manual switching is required. The input validator accepts both alphabets simultaneously.

Any byte with value ≥ 128 has its MSB (most significant bit) set. In two's complement signed representation, this indicates a negative number. Specifically, int8 value = uint8 value − 256 when uint8 ≥ 128. So byte 0xFF is 255 as uint8 but −1 as int8. Both are correct interpretations of the same raw byte.

Yes. The converter strips all whitespace characters (spaces, tabs, newlines, carriage returns) before processing. This handles PEM-formatted blocks, email-encoded MIME attachments, and copy-paste artifacts. Only the Base64 alphabet characters and padding are retained for decoding.

The tool processes inputs in the browser's main thread for strings under 100 KB of Base64 (≈75 KB decoded). For typical use cases (keys, tokens, small binary payloads), this is more than sufficient. Inputs beyond this threshold will still work but may cause brief UI blocking. The converter reports the exact decoded byte count so you can verify completeness.