This post walks through exactly what happens, with one small worked example you can check yourself, and the two fixes that actually work.

Disclosure: I built base64decodetool.com, including the URL-safe Base64 tool linked below. All values in this post are illustrative; there are no real tokens or credentials anywhere in it.

The three characters that cause the trouble

Standard Base64 (RFC 4648, section 4) uses 64 characters: A–Z, a–z, 0–9, plus + and /, with = as padding at the end. Those last three are the problem, because all of them mean something in a URL:

• + in a query string is read as a space by HTML form decoding (application/x-www-form-urlencoded), which is what most server frameworks and URLSearchParams use.
• / is a path separator. Inside a query value it is usually tolerated, but inside a path segment it splits the path.
• = separates a parameter's name from its value. Extra = signs at the end of a value are often kept, but some parsers, proxies or logging tools trim or mangle them.

So a Base64 string that is perfectly valid on its own can be quietly changed the moment you drop it into ?data=... without encoding it.

A worked example: price>=100?

Take the short, made-up text price>=100? (11 bytes of ASCII).

Step 1: standard Base64. Encoding it gives:

cHJpY2U+PTEwMD8=

Notice the + in the middle and the = at the end. Eleven bytes is not a multiple of three, so there is one padding character (11 bytes → 4 × ceil(11/3) = 16 characters).

Step 2: put it in a URL without encoding.

https://example.com/report?d=cHJpY2U+PTEwMD8=

Step 3: read it back on the server. With form-style query decoding, for example new URLSearchParams("d=cHJpY2U+PTEwMD8=").get("d") in JavaScript, you get:

cHJpY2U PTEwMD8=

The + is now a space.

Step 4: decode that. What happens next depends on the decoder. A strict decoder (Python's base64.b64decode with validate=True, for example) rejects the space and throws an error. That is the lucky case, because you notice. A lenient decoder that throws away anything that is not a Base64 character gives you cHJpY2UPTEwMD8=, which is now the wrong length and the wrong bits. Decoding that produces the bytes 70 72 69 63 65 0F 4C 4C 0C 0F, which shows up as price followed by control characters and LL. The first five letters survive, everything after the + is shifted, and nothing tells you why.

I checked those exact bytes with Node's atob after the same cleanup step a lenient decoder does. It is a good illustration of why "it decodes without an error" does not mean "it decoded correctly".

Fix 1: percent-encode the value

If the receiving side expects standard Base64, encode the value as a URL component before putting it in the URL:

const b64 = "cHJpY2U+PTEwMD8=";
const url = "https://example.com/report?d=" + encodeURIComponent(b64);
// ...?d=cHJpY2U%2BPTEwMD8%3D

%2B is a literal plus and %3D is a literal equals sign, so the server's query parser gives you back exactly cHJpY2U+PTEwMD8=. Most HTTP client libraries do this for you when you pass parameters as an object instead of building the string by hand, which is another good reason to stop concatenating URLs.

Fix 2: use Base64URL from the start

RFC 4648 section 5 defines a URL- and filename-safe alphabet that swaps the two problem characters:

The same text, price>=100?, becomes:

cHJpY2U-PTEwMD8

Nothing in that string needs escaping in a query value or a path segment. This is why JWTs, many signed-URL schemes and lots of API tokens use Base64URL rather than plain Base64.

In code:

// Node.js 16+
Buffer.from("price>=100?").toString("base64url"); // "cHJpY2U-PTEwMD8"

import base64
base64.urlsafe_b64encode(b"price>=100?").rstrip(b"=")  # b'cHJpY2U-PTEwMD8'

When you decode, convert - back to + and _ back to /, then add = until the length is a multiple of 4. Python's urlsafe_b64decode does the character swap but still needs the padding put back, which trips people up.

Which fix should you pick?

• You control both ends: use Base64URL. It is shorter (no padding), it survives URLs, cookies and filenames untouched, and you never have to remember to escape.
• The other side insists on standard Base64: keep it, but always percent-encode it as a URL component, and let your HTTP library build the query string.
• You are debugging a value that already went through a URL: look for spaces where a + should be. Replacing spaces with + before decoding can rescue the data, but treat that as a patch, not a design.

A quick checklist when a Base64 value "decodes to garbage"

1. Did it pass through a URL, a form post or a cookie? Check for spaces (lost +), missing = or %2B/%2F left undecoded.
2. Is the length a multiple of 4 after you add padding back? If it is 1 more than a multiple of 4, characters were lost.
3. Is it actually Base64URL (contains - or _)? Decode with the URL-safe alphabet.
4. Does the output start correctly and then go wrong? The break point is usually right where a + or / used to be.

How to check it with the tool

1. Open the URL-safe Base64 encoder and decoder. This page always works in the URL-safe format.
2. Choose Encode to Base64, type your text (for example price>=100?) and press Convert. You should see cHJpY2U-PTEwMD8.
3. Switch to Decode Base64, paste a value and press Convert. It accepts both alphabets and adds missing padding, so cHJpY2U-PTEwMD8 and cHJpY2U+PTEwMD8= both give price>=100?.

One honest caveat: like many lenient decoders, the tool quietly drops characters that are not part of either Base64 alphabet, including spaces. If you paste cHJpY2U PTEwMD8= it will not warn you about the missing +; it will show the broken result from the example above. If the output looks wrong, compare the input against the checklist first.

Everything runs in the browser, but as with any tool, don't paste real secrets or production tokens.

So when a hash utility prints hex and your config file wants Base64, or a log gives you Base64 and you want to look at the bytes, you have to convert. Below I explain how the conversion works, walk through an example by hand, list the mistakes that cause most failed conversions, and finish with a short guide to the free converter I built.

Same bytes, two alphabets

Take the five ASCII bytes of the sample word Hello:

• Hex: 48656c6c6f. Each byte is two characters from 0-9a-f.
• Base64: SGVsbG8=. Every 3 bytes become 4 characters from A-Z a-z 0-9 + /, and = pads the end when the byte count isn't a multiple of 3.

Both strings describe exactly the same bytes: 0x48 0x65 0x6c 0x6c 0x6f. Converting from one to the other is a two-step job. First decode the text back into bytes, then encode those bytes in the other format. You never need to go through "text" or a character set, which is why the conversion is lossless for any binary data, not only ASCII.

Worked example: converting by hand

Here is the first chunk, the illustrative hex input 48656c, worked out step by step.

Step 1: hex to bytes. Split the input into pairs: 48, 65, 6c. That gives three bytes.

Step 2: bytes to bits.

48 → 01001000
65 → 01100101
6c → 01101100

Joined together: 010010000110010101101100 (24 bits).

Step 3: regroup into 6-bit chunks. Base64 uses 6 bits per character, because 2^6 = 64:

010010 | 000110 | 010101 | 101100
  18   |   6    |   21   |   44

Step 4: look up the Base64 alphabet. Indexes 0–25 are A–Z, 26–51 are a–z, 52–61 are 0–9, then + and /.

• 18 → S
• 6 → G
• 21 → V
• 44 → s (44 − 26 = 18, the 19th lowercase letter)

Result: 48656c → SGVs. For the full 48656c6c6f, the last two bytes (6c 6f) are only 16 bits. They get zero-padded to 18 bits, which gives three characters (bG8), and one = brings the length up to a multiple of 4. The whole answer is SGVsbG8=.

Check: I ran both directions in Python and through the same JavaScript logic the converter page uses:

import base64, binascii
print(base64.b64encode(bytes.fromhex("48656c6c6f")).decode())  # SGVsbG8=
print(binascii.hexlify(base64.b64decode("SGVsbG8=")).decode())  # 48656c6c6f

A practical example: a SHA-256 hash for an SRI attribute

Command-line hash tools usually print hex. Subresource Integrity attributes (integrity="sha256-...") expect the same digest in Base64. A safe public value to practise on is the SHA-256 of an empty input. It's a well-known constant, not a secret:

• Hex (64 characters): e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
• Base64 (44 characters): 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=

The lengths show the size trade-off. A 32-byte digest takes 64 hex characters (2 per byte) but only 44 Base64 characters (4 per 3 bytes, rounded up). That's about 31% shorter, which is why APIs and HTML attributes tend to prefer Base64.

A common mistake is Base64-encoding the hex text instead of the bytes. Encode the 64-character string e3b0c4... as text and you get a much longer value, and it won't match anything a browser computes.

A sniff test: recognising file types

Hex-to-Base64 conversion also helps you spot what a mystery blob is. Every PNG starts with the public 8-byte signature 89504e470d0a1a0a, which in Base64 is iVBORw0KGgo=. So if a log line or JSON field begins with iVBORw0KGgo, it's almost certainly a PNG and not ciphertext. Likewise, the JPEG start bytes ffd8ffe0 become /9j/4A==, so Base64 that begins with /9j/ is usually a JPEG.

Mistakes that cause most failed conversions

• 0x prefixes. 0x48 0x65 is a common way to write two bytes, but the 0 in each 0x is a valid hex digit. Many tools (including mine, see below) strip the x but keep the 0, so you either get an "odd length" error or silently wrong bytes. Remove every 0x before converting.
• Odd number of hex digits. Every byte needs exactly two digits, so abc is not a complete byte string. Find the missing leading zero (often 0a written as a).
• URL-safe Base64. Base64URL replaces + and / with - and _ and often drops the = padding. That's what you'll find in JWTs and many web tokens. A strict decoder may reject it, so map -→+ and _→/ and pad to a multiple of 4.
• Pasting a whole data URI. data:image/png;base64, is a label, not data. Convert only what comes after the comma.
• Mixing up the modes. A string like eyJhbGciOi... is Base64URL (a JWT header). It is not hex, because hex contains only 0-9 and a-f/A-F.

How to use the converter

Open https://base64decodetool.com/hex/

1. Click Hex to Base64 or Base64 to Hex at the top of the tool.
2. Paste into the input box. Its label changes to Hex String Input or Base64 Input, and the result appears straight away under Base64 Output or Hexadecimal Output. Load Sample fills in 48656c6c6f20576f726c64 ("Hello World", output SGVsbG8gV29ybGQ=) if you want to test it first.
3. Click Copy to take the result. Swap Inputs moves the output into the input and flips the direction, which is a quick way to check a round trip. Clear empties the box.

A few honest notes on how the page behaves (I checked its JavaScript today):

• In Hex to Base64 mode it removes any character that isn't hex before converting. Spaces, colons and line breaks in pasted dumps are fine (89 50 4E 47 0D 0A 1A 0A still gives iVBORw0KGgo=). The catch is that a stray typo gets dropped without a warning instead of raising an error, and 0x prefixes cause the problem described above. Clean up your input first.
• In Base64 to Hex mode it accepts URL-safe characters and missing padding (3q2-7w gives DE AD BE EF). The hex output is uppercase and space-separated, so remove the spaces if your next tool wants one continuous string.
• If you paste a full data URI that has = padding into Base64 to Hex, it currently shows an error. Paste only the part after base64,.

Encoding is not encryption

Anyone can reverse hex or Base64 in one step. Use them to move bytes through text-only channels. For secrecy use real encryption, and for stored passwords use a proper password hash, not a reversible encoding.

Disclosure

I built the free Hex ↔ Base64 converter at https://base64decodetool.com/hex/. All values in this post are illustrative samples ("Hello", the public PNG/JPEG signatures and the SHA-256 of empty input). The converter runs in your browser, but as a habit, don't paste live production secrets into any online tool.

If you've ever called btoa() on user input in the browser, you've probably seen this:

Uncaught InvalidCharacterError: Failed to execute 'btoa' on 'Window':
The string to be encoded contains characters outside of the Latin1 range.

That message is from Chrome. Other browsers word it differently, but it's the same InvalidCharacterError DOMException. It shows up as soon as someone types an emoji, a Hindi name, or a Chinese address.

The quick fix you find online is a snippet built on the long-deprecated unescape(encodeURIComponent(...)) trick. A better fix is understanding why it happens. Base64 encodes bytes, not characters, so you have to decide how your text becomes bytes before you encode it.

What btoa() actually expects

MDN's btoa page puts it plainly: the input is a "binary string", and every character must have a code point below 256, because each character is treated as one byte. JavaScript strings are UTF-16, so anything above U+00FF can't fit in a byte, and btoa() throws.

There's a nasty middle case, though. Accented Latin letters like é (U+00E9) are below 256, so btoa("café") doesn't throw. It quietly encodes é as the single byte 0xE9, which is Latin-1, not UTF-8:

btoa("café");   // "Y2Fm6Q=="  (Latin-1 bytes, no error)

Hand that to a Python service or a Go API that decodes as UTF-8 and you get caf�. No error is raised anywhere. You just get a corrupted name in the database.

The fix: turn text into UTF-8 bytes first

UTF-8 is what almost every API, JSON parser and database expects, so encode to UTF-8 first and Base64 second.

Browser (and Deno/Node), using TextEncoder:

function toBase64Utf8(text) {
  const bytes = new TextEncoder().encode(text);   // UTF-8 bytes
  let binary = "";
  for (const b of bytes) binary += String.fromCharCode(b);
  return btoa(binary);                            // now every char is < 256
}

For very large inputs, build the binary string in chunks rather than one character at a time. Newer runtimes also have Uint8Array.prototype.toBase64(), which MDN marks as Baseline 2025. Check that your targets support it before you rely on it.

Node.js:

Buffer.from("Hi 👋", "utf8").toString("base64");   // "SGkg8J+Riw=="

Python:

import base64
base64.b64encode("Hi 👋".encode("utf-8")).decode("ascii")   # 'SGkg8J+Riw=='

Worked examples: three illustrative strings

I encoded three made-up sample strings as UTF-8 and checked the results three ways: the encoder's own JavaScript run in Node, Node's Buffer, and Python's base64 module. All three matched.

A few things stand out:

• é takes 2 bytes in UTF-8 (C3 A9), which is why café gives Y2Fmw6k= and not the Latin-1 Y2Fm6Q==.
• 👋 is 4 bytes (F0 9F 91 8B). JavaScript reports "Hi 👋".length as 5 because the emoji is a surrogate pair, while Python's len() says 4. Neither number is the byte count.
• Each Devanagari letter or sign is 3 bytes. नमस्ते is 6 code points (and only 3 visible clusters on screen), but 18 bytes.

The size math: count bytes, not characters

Base64 (RFC 4648, section 4) turns every 3 bytes into 4 characters and pads the end with =:

base64_length = 4 × ceil(utf8_bytes / 3)

• café: 4 × ceil(5/3) = 4 × 2 = 8. 5 bytes is one full group plus 2 left over, which gives one =.
• Hi 👋: 4 × ceil(7/3) = 4 × 3 = 12. 1 byte left over gives ==.
• नमस्ते: 4 × ceil(18/3) = 4 × 6 = 24. 18 is a multiple of 3, so no padding.

This matters when a field has a length limit. A 100-character Hindi name can be around 300 UTF-8 bytes, which becomes about 400 Base64 characters. If you size the column from the character count, you'll truncate it.

Same text, different bytes, different Base64

There's no single "Base64 of a string" until you choose a character encoding. Here's the same input in other encodings (checked with Python):

UTF-16LE is what you'll run into with Windows APIs and PowerShell's -EncodedCommand. Notice that नमस्ते is actually shorter in UTF-16 (12 bytes) than in UTF-8 (18 bytes). If two systems produce different Base64 for "the same" text, a mismatched encoding is the first thing I check.

Decoding back without mojibake

atob() has the mirror-image problem. It returns a binary string, one character per byte, so atob("Y2Fmw6k=") gives café. You need to rebuild the bytes and decode them as UTF-8:

function fromBase64Utf8(b64) {
  const binary = atob(b64);
  const bytes = Uint8Array.from(binary, (ch) => ch.charCodeAt(0));
  return new TextDecoder("utf-8", { fatal: true }).decode(bytes);
}
fromBase64Utf8("4KSo4KSu4KS44KWN4KSk4KWH");   // "नमस्ते"

{ fatal: true } makes TextDecoder throw a TypeError on bytes that aren't valid UTF-8. Without it, you get a silent �. Feeding it the Latin-1 Y2Fm6Q== throws, which is the result you want. In Python, use base64.b64decode(s).decode("utf-8"), and in Node, Buffer.from(s, "base64").toString("utf8").

How to use the encoder

1. Open base64decodetool.com/encode/. Make sure Encode to Base64 is selected and Character Set is UTF-8.
2. Type or paste into Input String. With Live Conversion on, the Base64 appears straight away. The counter under the input shows characters and bytes (for Hi 👋 it reads 5 chars / 7 B).
3. Turn on URL-Safe Format if the value is going into a URL or JWT-style token (Hi 👋 becomes SGkg8J-Riw). Then click Copy, or Swap Inputs to decode it back.

The encoding runs in your browser. Still, test with sample text like the strings above rather than real customer data.

En este artículo vamos a hacerlo con un ejemplo real y comprobable: crearemos una imagen diminuta, la convertiremos a Base64, la usaremos en CSS y en HTML, y verificaremos que al decodificarla obtenemos exactamente los mismos bytes.

Divulgación: la herramienta que enlazo, Convertir Imagen a Base64, la creó Nagesh, el autor de este blog.

Qué es un data URI

Un data URI tiene esta forma:

data:[tipo MIME];base64,[datos codificados]

Para un PNG sería data:image/png;base64, seguido de la cadena Base64. El navegador lo trata como si fuera un archivo: puedes ponerlo en src de una etiqueta <img> o dentro de url() en CSS.

Ejemplo práctico: un PNG de 2×2 píxeles

Los datos de este ejemplo son ilustrativos: la imagen la generé yo mismo para el artículo, no proviene de ningún proyecto real.

Creé con Python (sin librerías externas, solo zlib y struct) un PNG de 2×2 píxeles con un patrón de tablero: rojo (255, 0, 0) y azul (0, 128, 255) alternados. El archivo resultante, punto.png, ocupa 75 bytes.

Para codificarlo, basta con la biblioteca estándar:

import base64

with open("punto.png", "rb") as f:
    datos = f.read()

b64 = base64.b64encode(datos).decode("ascii")
print(len(datos), len(b64))   # 75 100
print("data:image/png;base64," + b64)

La salida Base64 real es (100 caracteres):

iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAIAAAD91JpzAAAAEklEQVR42mP4z8DA0PAfhIEEACLyBP2KEV+xAAAAAElFTkSuQmCC

Y el data URI completo (122 caracteres):

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAIAAAD91JpzAAAAEklEQVR42mP4z8DA0PAfhIEEACLyBP2KEV+xAAAAAElFTkSuQmCC

Fíjate en que todos los PNG empiezan por iVBORw0KGgo: es la firma binaria del formato (89 50 4E 47 0D 0A 1A 0A) vista en Base64. Si una cadena que dice ser PNG no empieza así, algo está mal.

Usarlo en CSS

.patron {
  width: 40px;
  height: 40px;
  background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAIAAAD91JpzAAAAEklEQVR42mP4z8DA0PAfhIEEACLyBP2KEV+xAAAAAElFTkSuQmCC");
  background-size: 8px 8px;
  image-rendering: pixelated; /* para que se vean los píxeles nítidos al ampliar */
}

Con background-size y la repetición por defecto, el PNG de 2×2 se convierte en un fondo de tablero rojo y azul.

Usarlo en HTML

<img
  src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAIAAAD91JpzAAAAEklEQVR42mP4z8DA0PAfhIEEACLyBP2KEV+xAAAAAElFTkSuQmCC"
  width="40" height="40"
  alt="Patrón de tablero rojo y azul"
  style="image-rendering: pixelated">

Escribe siempre un alt descriptivo: que la imagen esté incrustada no cambia nada en accesibilidad.

Comprobación: ida y vuelta

Una codificación correcta debe ser reversible sin pérdidas:

assert base64.b64decode(b64) == datos   # True

En mi prueba, decodificar la cadena devolvió exactamente los mismos 75 bytes (huella SHA-256 34391be6…77ba00 en ambos casos). Además descargué el JavaScript público de la página de la herramienta y ejecuté con Node.js sus funciones de codificación y decodificación sobre el mismo archivo: produjeron la misma cadena de 100 caracteres que Python, y la decodificación devolvió los 75 bytes idénticos. Para la lectura del archivo, la página usa el FileReader.readAsDataURL() estándar del navegador, que genera el mismo formato data:image/png;base64,….

El coste: aproximadamente un 33 % más

Base64 representa cada 3 bytes con 4 caracteres, así que el tamaño crece en un factor de 4/3 (más el relleno = cuando la longitud no es múltiplo de 3):

En nuestro ejemplo el aumento es exactamente del 33,3 %; con el prefijo, el texto final ocupa un 63 % más que el archivo. En un icono de 75 bytes da igual, pero en una foto de 300 KB serían unos 400 KB de texto (cálculo ilustrativo) metidos dentro de tu CSS. La compresión gzip o Brotli del servidor reduce parte de esa diferencia, pero no toda.

Base64 no es cifrado

Base64 es solo una codificación: cualquiera puede revertirla en un segundo, sin clave. No sirve para ocultar ni proteger una imagen. Si incrustas algo en tu CSS, es tan público como un archivo enlazado.

¿Cuándo usar data URIs y cuándo no?

Úsalos para:

• Iconos y patrones muy pequeños (unos pocos KB como máximo).
• Imágenes críticas para el primer pintado que no quieres que dependan de otra petición.
• Correos HTML, prototipos o archivos HTML autocontenidos.

Evítalos para:

• Fotos o imágenes grandes: inflan el CSS/HTML y retrasan el renderizado de toda la página.
• Imágenes que se reutilizan en varias páginas: un archivo aparte se guarda en la caché del navegador una sola vez; un data URI se vuelve a descargar cada vez que cambia el CSS o el HTML que lo contiene.
• Iconos SVG: muchas veces es mejor incrustar el SVG como texto (codificado para URL) que en Base64.

Nota sobre CSP: si tu sitio usa Content Security Policy, las imágenes con data: solo se cargarán si la directiva lo permite, por ejemplo img-src 'self' data:. Si un icono incrustado no aparece, revisa la consola del navegador antes de culpar a la cadena Base64.

Cómo usar la herramienta

La página base64decodetool.com/es/image/ está en español, pero algunos botones aparecen en inglés (comprobado el 10 de noviembre de 2026):

1. Pulsa Select Image o arrastra el archivo a la zona "Arrastre y suelte la imagen aquí o haga clic para buscar" (admite PNG, JPG, WEBP, GIF y SVG de hasta 50 MB; todo se procesa en el navegador).
2. Elige el formato de salida en las pestañas DataURL, HTML, CSS o Raw (la pestaña CSS genera la línea background-image: url("…");).
3. Pulsa Copiar y pega el resultado en tu código. Si usas la pestaña HTML, cambia el texto alt genérico por uno descriptivo.
4. Para el proceso inverso, pega la cadena en Paste Image Base64 String, pulsa Decode & Preview y luego Download Image.

Resumen

Un data URI es simplemente el archivo en Base64 con el prefijo data:tipo/mime;base64,. Es ideal para iconos diminutos, cuesta alrededor de un 33 % más de tamaño, no protege nada y conviene comprobarlo siempre con una decodificación de ida y vuelta. Con imágenes pequeñas, la ganancia de una petición menos compensa; con imágenes grandes, casi nunca.

Base64 sering dipakai untuk membawa data biner lewat saluran teks: lampiran email, data URI, atau JSON. Masalahnya, alfabet standar memakai + dan /, ditambah padding = di akhir. Ketiga karakter itu punya arti khusus di URL: + bisa dibaca sebagai spasi di query string, / memisahkan path, dan = memisahkan nama dan nilai parameter. Karena itu ada Base64URL (RFC 4648 bagian 5): alfabetnya sama, tetapi + diganti -, / diganti _, dan padding biasanya dibuang.

Artikel ini membedakan keduanya dengan contoh yang bisa Anda ulang sendiri, lalu menunjukkan cara mencobanya di versi Indonesia alat URL-safe.

Apa saja yang berubah

Penting: keduanya adalah pengodean, bukan enkripsi. Siapa pun yang memegang string bisa mendekodenya. Mendekode JWT juga bukan validasi: memeriksa token tetap butuh verifikasi tanda tangan, alg, exp, iss, dan klaim lain di sisi server.

Contoh 1: teks pendek "Halo"

Teks Halo dalam UTF-8 adalah 4 byte. Hasil Base64 standar:

SGFsbw==

Versi Base64URL:

SGFsbw

Tidak ada + atau / di sini, jadi bedanya hanya padding. Hitungannya: 4 byte = 32 bit. Base64 mengelompokkan per 6 bit, jadi butuh 6 karakter data, lalu standar menambah == agar panjangnya kelipatan 4 (8 karakter). Base64URL cukup berhenti di 6 karakter.

Contoh 2: byte yang memunculkan + dan /

Tiga byte sintetik FB FF BF (dalam heksadesimal):

• Base64 standar: +/+/
• Base64URL: -_-_

Contoh berbasis teks: >>> menjadi Pj4+ di Base64 standar dan Pj4- di Base64URL.

Bayangkan Anda menaruh +/+/ di https://contoh.id/unduh?id=+/+/. Server bisa membaca + sebagai spasi, dan string yang sampai sudah rusak. Versi -_-_ tiba utuh tanpa percent-encoding.

Contoh 3: header JWT sintetik

Header JSON berikut:

{"alg":"HS256","typ":"JWT"}

di-encode Base64URL tanpa padding menjadi string yang sering Anda lihat di awal token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload dan signature memakai aturan yang sama, lalu ketiganya digabung dengan titik. Itulah sebabnya Anda tidak pernah melihat +, /, atau = di JWT yang benar.

Mengembalikan padding saat decode

Beberapa decoder Base64 standar menolak string tanpa =. Aturannya sederhana: hitung panjang % 4.

• Sisa 0: tidak perlu apa-apa.
• Sisa 2: tambahkan ==.
• Sisa 3: tambahkan =.
• Sisa 1: string tidak valid (biasanya terpotong saat disalin).

Contoh: SGFsbw panjangnya 6, sisa 2, jadi menjadi SGFsbw==. Ganti juga - menjadi + dan _ menjadi / sebelum memakai decoder standar.

Di Python, semuanya tinggal satu baris:

import base64
base64.urlsafe_b64encode(b">>>").rstrip(b"=")   # b'Pj4-'
base64.urlsafe_b64decode("SGFsbw" + "==")       # b'Halo'

Di JavaScript modern (browser atau Node), btoa menghasilkan Base64 standar, jadi Anda perlu mengganti karakter sendiri: .replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "").

Kesalahan yang sering terjadi

1. Double-encoding. String Base64URL di-percent-encode lagi, atau di-encode Base64 dua kali. Hasilnya tetap bisa didekode, tetapi isinya string Base64, bukan data asli.
2. Mencampur alfabet. Data diencode dengan +// lalu didekode dengan decoder URL-safe yang ketat, atau sebaliknya. Gejalanya: error "invalid character" di tengah string.
3. Menganggap Base64URL sebagai penyamaran. Data sensitif di URL tetap tercatat di log server dan riwayat browser, apa pun encoding-nya.

Cara memakai alat (label UI Bahasa Indonesia)

Buka base64decodetool.com/id/url-safe/. Di halaman ini, sakelar Format Aman URL sudah aktif dan terkunci, jadi hasil encode otomatis memakai -/_ tanpa =.

1. Pilih tab Enkode ke Base64 (atau Dekode Base64 untuk arah sebaliknya).
2. Biarkan Set Karakter di UTF-8 untuk teks, atau pilih Hexadecimal lalu ketik fbffbf untuk mengulang Contoh 2.
3. Ketik input, misalnya Halo atau >>>, lalu tekan Konversi.
4. Periksa String Output, lalu tekan Salin.

Semua proses berjalan di browser Anda; string tidak dikirim ke server alat.

Kapan memakai yang mana

• Base64URL: segmen JWT, token di URL, tautan reset kata sandi, WebAuthn, ID di path atau query.
• Base64 standar: data URI (data:image/png;base64,...), lampiran MIME email, dan file konfigurasi yang tidak hidup di URL.

Ringkasan

Base64URL adalah Base64 dengan - dan _ menggantikan + dan /, biasanya tanpa =. Gunakan untuk apa pun yang lewat URL atau JWT, kembalikan padding dengan aturan panjang % 4 saat decode, dan ingat bahwa ini tetap pengodean, bukan keamanan. Untuk latihan, ulangi tiga contoh sintetik di atas di alat Base64 aman URL.