Base64 Decoding in JavaScript/Browser: A Complete Guide

It arrives in a dozen different disguises: a JWT tucked into an Authorization header, an image/png blob inside a JSON response, a Sec-WebSocket-Accept value in a handshake log, an email attachment wrapped in MIME, a value your backend politely stuffed into a query string. The string itself always looks the same: a long run of letters, digits, the occasional + or /, and maybe an = or two at the end. If the home page of this site taught you what Base64 is - four printable characters standing in for every three bytes, with = padding to finish the last group - then this article is about the part you actually do in code: turning those characters back into bytes, and the bytes back into meaning, using nothing but what the browser already ships.

Two quick ground rules before we start. First, decoding is the shrinking direction: for every four characters you read in, three bytes come out, so the output always fits into less memory than the input. Second, a decoded Base64 string is not automatically text. It is bytes, and bytes may turn out to be UTF-8, Windows-1252, a PNG header, or a cryptographic signature. The single most common bug in Base64 code is forgetting which of those you are holding, so the sections below are organized around that question.

The Three Layers of Decoding

Modern browsers give you three native layers, and the good news is that no package is ever required. Each one answers a slightly different question, and picking the right one saves you from a lot of copy-pasted Stack Overflow snippets:

The shape of the whole article follows from that table. atob() is the workhorse you will meet everywhere, including in old code. TextDecoder is the bridge from bytes to words. And Uint8Array.fromBase64() is the 2025 upgrade that skips the middle step entirely when you only wanted bytes all along.

atob: Fast, Forgiving, and Very Old

The entire contract fits in one line: atob(encodedData). It takes a Base64-encoded string and returns a "binary string": a regular JavaScript string in which every character holds exactly one decoded byte, a code point from 0 to 255. That return type matters, because it is not the same thing as readable text (more on that below), but for a start the function is as quick as it gets and it has been around for a very long time: Chrome 4, Firefox 1, Safari 3, and - this is the one most people remember - only Internet Explorer from version 10 onward, which is why code written before 2012 is full of hand-rolled Base64 tables.

What makes atob() pleasant is how much it forgives before it gives up. The WHATWG HTML standard says to ignore all ASCII whitespace - spaces, tabs, line feeds, carriage returns - before decoding, so a MIME-wrapped string with newlines every 76 characters decodes without any cleanup on your part. Missing padding is forgiven, too. But the moment it sees a character outside the alphabet, or a length that could never be valid, it throws a DOMException named InvalidCharacterError. No silent garbage, no partial results.

Here is the damage report, row by row:

One practical note: the error message itself differs between engines (Firefox says "String contains an invalid character", Chrome says the string "contains characters outside of the Latin1 range"), so catch on the exception name, not on the message text.

From Raw Bytes to Real Text

That "binary string" return type deserves a full stop, because it is the source of most decoding confusion. JavaScript strings are UTF-16, so atob() hands you a string whose characters are byte values, not readable glyphs. If your payload was the UTF-8 encoding of the text "hello 你好", printing the result directly gives you mojibake. The fix is a two-step decode: Base64 to bytes, then bytes to text.

First, the Base64-to-bytes step. This small helper is the classic recipe and is worth keeping in your pocket, because it is the load-bearing piece of most of the examples in this article:

function base64ToBytes (base64) {
  const binary = atob(base64);
  const bytes = new Uint8Array(binary.length);
  for (let i = 0; i < binary.length; i += 1) {
    bytes[i] = binary.charCodeAt(i);
  }
  return bytes;
}

Then the bytes-to-text step, with TextDecoder. For UTF-8 (the default, and the right choice for JSON, JWT payloads, and most web data) the call is one line:

const bytes = base64ToBytes('aGVsbG8g5L2g5aW9');
const text = new TextDecoder('utf-8').decode(bytes);
console.log(text); // "hello 你好"

Why two steps at all? Because atob() has no idea what character set the bytes were produced in. It is a pure bit converter. TextDecoder is the component that interprets bytes as a charset, and it accepts a label for the job: utf-8, windows-1252, iso-8859-1, utf-16le, and roughly eighty other labels. Data that came out of a 1990s application is usually Windows-1252, and one constructor argument is all it takes:

const decoder = new TextDecoder('windows-1252');
const text = decoder.decode(bytes); // same bytes, different interpretation

The TextDecoder constructor also takes a fatal flag, and it is worth setting to true whenever the decoded text feeds something important. By default the decoder is lenient: invalid byte sequences are quietly replaced with the Unicode replacement character, U+FFFD, and you are never told. With fatal: true, the same damage throws a TypeError instead of hiding:

const strict = new TextDecoder('utf-8', { fatal: true });
try {
  strict.decode(corruptedBytes);
} catch (error) {
  console.log(error.name); // "TypeError"
}

This is one of those switches that looks minor in the docs and looks like a data incident in production. If your input is user-supplied or network-supplied, decode strictly and handle the error on purpose.

URL-Safe Input Needs a Detour

One variant of Base64 deserves its own section, because it shows up constantly in the wild and atob() will not read it. It is the URL and filename safe alphabet from section 5 of RFC 4648, usually called base64url: the same 64 characters, except that + and / are replaced by - and _, and the = padding is often dropped, since the data length is known implicitly. The swap exists for a concrete reason: in a URL, + means a space and / starts a path segment, so the standard alphabet would have to be percent-encoded character by character. Base64url travels cleanly in query strings, path segments, fragments, and filenames.

The catch is that the two alphabets are not interchangeable, and atob() only speaks the standard one. Pass it a - or _ and you get InvalidCharacterError. You have two clean options.

Option one, which works everywhere: convert the alphabet and restore the padding before calling atob():

function fromUrlBase64 (segment) {
  let s = segment.replace(/-/g, '+').replace(/_/g, '/');
  const missing = (4 - (s.length % 4)) % 4;
  return atob(s + '='.repeat(missing));
}
console.log(fromUrlBase64('aGVsbG8')); // "hello"

The (4 - (s.length % 4)) % 4 expression is the whole trick: it computes how many = characters a well-padded string of that length would need, from zero up to two.

Option two, in 2025+ browsers: the new native decoder takes the alphabet as an option, so no string surgery at all:

const bytes = Uint8Array.fromBase64('P3-0', { alphabet: 'base64url' });
console.log(Array.from(bytes).join(', ')); // "63, 127, 180"

Two rules keep you out of trouble. Never mix alphabets inside a single value - a decoder that sees both a + and a - has no way to know which family it is reading, and the spec-correct behavior is to fail. And agree with the other side of the wire on whether padding is present: dropping it is legal for base64url, so a receiver must be ready for both shapes. atob() already is; the native options below give you a dial for it.

The 2025 Shortcut: Uint8Array.fromBase64

If you look back at the base64ToBytes helper, you will notice it does two things: decode Base64, then copy the characters into a byte array one by one in JavaScript. That copy loop is the slow, avoidable part, which is exactly what the new ECMAScript method removes. Uint8Array.fromBase64(string, options) goes straight from the encoded string to a byte array, and it ships in Chrome 140, Edge 140, Firefox 133, Safari 18.2, Node 25 and Deno 2.5 - the first JavaScript platform feature of its kind to land, marked Baseline 2025 by the web platform working group.

The options object has two dials. The first is alphabet: "base64" (the default) or "base64url". The second is lastChunkHandling, which controls what happens to the final partial group of characters:

Like atob(), the method ignores ASCII whitespace in the input, so wrapped lines are fine. Unlike atob(), it is opinionated about everything else: a character outside the selected alphabet, or a last chunk that violates the chosen mode, throws a SyntaxError; passing something that is not a string throws a TypeError. Here is strict mode at work, rejecting a chunk whose padding is missing:

const ok = Uint8Array.fromBase64('SGVsbG8=', { lastChunkHandling: 'strict' });
try {
  Uint8Array.fromBase64('VR', { lastChunkHandling: 'strict' });
} catch (error) {
  console.log(error.name); // "SyntaxError"
}

Performance is the other reason to prefer it. On a recent Firefox, decoding a 10 megabyte payload takes single-digit milliseconds with fromBase64, while the classic atob plus character-by-character byte mapping takes about twenty times as long, because the slow part is the JavaScript-level loop, not the Base64 math. If your data is bytes, skip the string entirely.

For older browsers, the situation is simple: keep the base64ToBytes helper above, or pull in a small polyfill (core-js and es-shims both ship one for fromBase64) if you want to write new-style code everywhere. The API is stable - it is in the ECMAScript specification now - so anything you write against it is not going to be deprecated.

Reading a JWT

The most common "mysterious string" in application logs is a JSON Web Token: three dot-separated segments, header.payload.signature, where the first two are Base64url-encoded JSON objects. Decoding one is a five-line affair, and it is a perfect warm-up for everything so far:

function jwtSegmentToBytes (segment) {
  let s = segment.replace(/-/g, '+').replace(/_/g, '/');
  s += '='.repeat((4 - (s.length % 4)) % 4);
  return base64ToBytes(s);
}
const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';
const [header64, payload64] = token.split('.');
const payload = JSON.parse(new TextDecoder().decode(jwtSegmentToBytes(payload64)));
console.log(payload.name); // "John Doe"

Now the part that beginners skip and production systems learn about the hard way: the payload is not verified by being decodable. Anyone can write a JWT with any payload they like; the signature segment is what ties it to a secret. Verifying an HS256 token in the browser uses the Web Crypto API, which needs the signature as bytes - another reason the segment-to-bytes helper earns its keep:

const encoder = new TextEncoder();
const key = await crypto.subtle.importKey(
  'raw',
  encoder.encode('shared-secret'),
  { name: 'HMAC', hash: 'SHA-256' },
  false,
  ['verify']
);
const [h, p, sig64] = token.split('.');
const valid = await crypto.subtle.verify(
  'HMAC',
  key,
  jwtSegmentToBytes(sig64),
  encoder.encode(h + '.' + p)
);
console.log(valid); // true only if the signature matches the secret

Three pitfalls deserve naming. First, check the header before you verify: a token that claims alg: "none" asks you to trust the payload without a signature, and naive code has been fooled into doing exactly that. Second, honor the time claims - exp, nbf, iat - after verification, not before. Third, the classic key-confusion attack: a server configured for RS256 but that will also accept HS256 lets an attacker sign tokens with the public key (which is public on purpose) used as an HMAC secret. In short: decode freely, trust nothing, verify everything.

Opening Data URLs

A data URL embeds a whole file inside a URL: data:, an optional media type, an optional ;base64 flag, a comma, then the payload. Text payloads are percent-encoded, binary payloads are Base64, and the browser renders them without any HTTP request - no fetch, no server round trip, nothing to cache. The browser treats each data URL as a unique opaque origin, which is also why they are a favorite vector for sneaky content: a data:text/html document opened in an iframe runs its scripts, and a restrictive Content-Security-Policy can block data URLs entirely. Keep your CSP in mind if you start handing these to user-controlled markup.

Decoding one is mostly string surgery, then the same bytes pipeline as before:

const url = 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+M9QDwADgQFY/fWoOgAAAABJRU5ErkJggg==';
const comma = url.indexOf(',');
const meta = url.slice(5, comma); // "image/png;base64"
const bytes = base64ToBytes(url.slice(comma + 1));
const blob = new Blob([bytes], { type: 'image/png' });
const objectUrl = URL.createObjectURL(blob);

The meta piece tells you the media type (image/png here, with the ;base64 marker confirming the payload is Base64). Once the payload is a Blob, everything normal applies: an object URL for an <img>, a download link, or a post to a server. The only real cost of the data-URL route is size - the payload sits about 33 percent larger than the original file - and a large image in a URL can strain the string limits of the page, which is another vote for object URLs when the file never needs to leave the browser.

Decoding Files That Arrive as Text

Files reach the browser two ways. The modern way is raw bytes: a fetch that you read as an ArrayBuffer, or a File from a picker that you read with file.arrayBuffer(). If you are on that path, congratulations - there is no Base64 in the picture at all, and you should stay on that path, because bytes cost nothing to carry while Base64 costs a third of extra bandwidth and memory for the privilege. The other way is when the channel is text-only: a JSON API that returns {"attachment": "data:application/pdf;base64,JVBERi..."}, an email attachment, a configuration string, a value in a database column. Then Base64 is the protocol, and your job is just to get the bytes out:

async function loadRemoteBytes (fileUrl) {
  const response = await fetch(fileUrl);
  return new Uint8Array(await response.arrayBuffer());
}
const record = JSON.parse(await (await fetch('/api/record/42')).text());
const pdfBytes = base64ToBytes(record.attachment.split(',')[1]);

Two notes on the second line. Splitting at the first comma is all it takes to peel off the data-URL header (the media type can contain no comma, so the first one is always the separator). And if the value is plain Base64 without a data-URL prefix, just skip the split. Email MIME parts are the same story with extra steps: the attachment body is Base64 wrapped at 76 characters per line, but since atob() skips whitespace, you can hand it the wrapped text exactly as it arrived in the raw message - no unwrapping required. That one behavior quietly saves a lot of regex.

Verifying a WebSocket Handshake

One of the more charming uses of decoding in the browser is checking the WebSocket handshake itself. RFC 6455 requires the client to send a Sec-WebSocket-Key header (16 random bytes, Base64-encoded), and the server to answer with Sec-WebSocket-Accept: the SHA-1 hash of the key concatenated with a fixed magic GUID, Base64-encoded. If the value does not match, the handshake fails and the connection is not upgraded. The whole point of this ceremony is that a server that only speaks HTTP cannot accidentally complete it - the magic GUID exists to make the computation look overcomplicated on purpose. And because the browser has both the hashing and the encoding, you can compute the expected answer yourself, which makes debugging proxies and gateways a one-liner:

const MAGIC = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
async function expectedAccept (clientKey) {
  const digest = await crypto.subtle.digest(
    'SHA-1',
    new TextEncoder().encode(clientKey + MAGIC)
  );
  return btoa(String.fromCharCode(...new Uint8Array(digest)));
}
const accept = await expectedAccept('dGhlIHNhbXBsZSBub25jZQ==');
console.log(accept); // "s3pPLMBiTxaQ9kYGzzhZRbK+xOo="

That last line is not a coincidence - it is the exact example from the RFC, reproduced byte for byte. When your gateway answers with anything else, now you know precisely which side of the equation is lying.

HTTP Headers and Query Strings

Base64 is a favorite for HTTP headers because headers must be ASCII, and the most famous case is Basic authentication: Authorization: Basic followed by the Base64 encoding of username:password. Reading such a header (say, while displaying what a request carries) is one split and one decode:

const header = 'Basic YWxpY2U6c2VjcmV0MTIz';
const [user, ...rest] = atob(header.slice(6)).split(':');
const password = rest.join(':');
console.log(user, password); // "alice secret123"

The spread-and-rejoin pattern handles the awkward-but-legal case of a password containing a colon, because the split point is always the first one after the username. The same pattern applies anywhere a header smuggles a structured value: Proxy-Authorization, some vendor-specific headers, and the occasional cookie. In query strings and deep links, Base64 appears when an app wants to share state without a server: an OAuth state value, a restored search form, a "resume where I left off" marker. Decode defensively - wrap in try/catch, because the value crossed a network boundary and anything can have happened to it - and treat what you get as untrusted input, full stop.

Which brings us to the sentence that should be pinned above every terminal: Base64 is not encryption. It is not even obfuscation in any real sense, because the "decryption" is one function call that every language on earth implements. If a value needs to stay secret, Base64-encoding it first makes it less safe, not more - it just adds a step for the attacker who is already going to get there.

State in the URL and in Storage

The same logic extends to anything that must survive a page reload or a share link. The usual suspects: localStorage and sessionStorage values that carry structured or binary data, the hash fragment of a URL for single-page-app routing state, and configuration blobs embedded in pages by build tools. The storage story is worth one concrete example, because the read side pairs with the write side you will want to remember:

const raw = localStorage.getItem('profile');
const profile = JSON.parse(new TextDecoder().decode(base64ToBytes(raw)));

Three things to keep in mind. First, budgets: browsers give each origin roughly 5 megabytes of localStorage, and your stored Base64 string eats about 33 percent more than the original data, so a 3.5 megabyte file quietly becomes 4.6 megabytes of storage - and the string lives in memory as UTF-16, which doubles the footprint again while the page is open. Second, consistency: encode and decode with the same character set on both sides, or you will store perfectly good bytes and read mojibake. Third, share links: if the state travels in the URL, use the URL-safe alphabet so the value survives copy-paste, and keep it short, because URL lengths above a couple of thousand characters start to make old clients and logging tools nervous.

When the Data Arrives in Pieces

Sometimes the Base64 does not arrive as one string: a WebSocket message boundary cuts it in half, a server-sent event stream drips it in, a chunked upload feeds it a few kilobytes at a time. You cannot call atob() on a fragment, because Base64 groups are 3-byte units expressed in 4-character blocks, and a cut in the middle of a group leaves a dangling partial. The old-school fix was to buffer characters until you had a multiple of four and decode the buffer in slices. The 2025 API makes this clean: Uint8Array.prototype.setFromBase64(string, options) writes decoded bytes into an existing array and returns an object with two numbers, read (how many characters it consumed) and written (how many bytes it produced). With lastChunkHandling: "stop-before-partial", it decodes only complete groups and leaves the partial tail unread, which is exactly the behavior a stream decoder wants:

const parts = [];
let carry = '';
for (const piece of incomingPieces) {
  let pending = carry + piece;
  for (;;) {
    const room = new Uint8Array(8);
    const result = room.setFromBase64(pending, {
      lastChunkHandling: 'stop-before-partial'
    });
    parts.push(room.subarray(0, result.written));
    pending = pending.slice(result.read);
    if (result.read === 0) {
      carry = pending;
      break;
    }
  }
}
const size = parts.reduce((sum, part) => sum + part.length, 0);
const bytes = new Uint8Array(size);
let at = 0;
for (const part of parts) {
  bytes.set(part, at);
  at += part.length;
}
const text = new TextDecoder().decode(bytes);

Read the inner loop slowly, because it is the whole pattern: feed in the carried-over remainder plus the new piece, let the decoder consume as many complete groups as fit, remember how much was left by slicing off result.read characters, and when nothing complete is left (result.read === 0) stash the remainder as the new carry and wait for the next piece. The Uint8Array(8) is just a scratch buffer - one group of four characters produces at most three bytes, so eight is generous. At the end, carry holds whatever the stream never finished, which is either your error signal or your "connection ended cleanly" check.

When Not to Decode Base64

A useful reference teaches you when to set the tool down. If you control both ends of the channel, reach for raw bytes instead: fetch with response.arrayBuffer() for downloads, file.arrayBuffer() for picker files, ArrayBuffer payloads in WebSockets, and multipart FormData for uploads. None of that touches Base64, and you get the data at full speed with none of the size tax and none of the string-in-memory footprint. Base64 earns its keep precisely when the channel is text-only: JSON bodies, query strings, email, storage, legacy APIs, and anything whose contract says "ASCII or bust". The moment a byte would do, a Base64 string is paying a 33 percent surcharge for the privilege of being printable, and the surcharge is collected in bandwidth, memory, and CPU - three bills you can all avoid.

Common Decoding Pitfalls

After all the happy paths, here is the list of ways this bites, in roughly the order you will meet them:

• Treating the result of atob() as text. It is a binary string. Through TextDecoder it becomes text; printed directly, it becomes mojibake. This single confusion causes most "Base64 does not work" reports.
• Expecting Unicode to just work. The bytes of "你好" are perfectly happy to decode, but they are still bytes until a decoder tells you they are UTF-8. Encode and decode in the same charset on both sides.
• Feeding base64url to atob(). A single - or _ throws. Convert the alphabet first, or use fromBase64 with the right option.
• Believing any long string is Base64. A valid Base64 string has a length that is a multiple of four (padding included) and uses at most one alphabet. A length of one modulo four is an instant fail - check it before you spend a try/catch on it.
• Trusting padding you did not agree on. Some systems strip =, some keep it, some add it in the middle of a wrapped string where it belongs. Agree with the sender, then decide whether to be lenient (atob) or strict (fromBase64).
• Silent corruption from a lenient decoder. A default TextDecoder replaces invalid bytes with U+FFFD and says nothing. Set fatal: true when the data matters.
• Assuming Base64 protects anything. It does not. It is a serialization format, one function call from plain text, and "we Base64 it so users cannot read it" is a security posture, not a control.
• Forgetting memory. A decoded binary string of one megabyte occupies two megabytes as a UTF-16 string, while a Uint8Array of the same data occupies one. For big payloads, go straight to fromBase64.
• Re-decoding on every render. Decoding a few megabytes is fast, but not free, and not once per frame. Decode once, cache the bytes, render from the cache.

Performance Notes

The short version: the native decoders are fast, and the slow part of old code is usually the JavaScript around them, not the Base64 itself. On a recent Firefox, a 10 megabyte payload decodes in single-digit milliseconds with Uint8Array.fromBase64; atob alone is a few times slower, and the classic follow-on loop that maps characters to a byte array takes roughly twenty times longer than fromBase64 for the same input, because it runs a million property writes on the main thread. Practical consequences: prefer fromBase64 where your audience has it; keep the atob helper where they do not; never build a byte array by concatenating strings in a loop; and if you must process a huge payload, consider handing the decoded Uint8Array to a Web Worker - the bytes transfer without copying, and the main thread stays free to keep the UI at 60 frames per second. And remember the direction of the math: decoding shrinks, so a decoded buffer always fits in less memory than the string it came from. You can never run out of memory by decoding; you can only run out of memory by keeping both the string and the bytes around longer than you need.

A Short History of Decoding in Browsers

Base64 predates the web, but the browser's decoders have a story worth knowing, because it explains why the ecosystem is full of relics. atob and its sibling btoa were part of the first HTML5 drafts around 2008, and engines shipped them early: Firefox from version 1 in 2004, Safari 3, Chrome 4. Internet Explorer skipped them entirely until IE 10 in 2011, which is why pre-2012 JavaScript is a museum of hand-rolled Base64 - lookup tables, String.fromCharCode gymnastics, and the infamous unescape(encodeURIComponent()) incantation for Unicode, a pair of functions that were deprecated in the language and survived in browsers for a decade out of sheer inertia. Then came the charset layer: TextEncoder and TextDecoder from the Encoding standard arrived between 2013 and 2017 (Firefox 18, Chrome 38, Safari 10.1, and never in any IE), finally giving the platform a principled way to turn bytes into words. Node.js, which never had atob or btoa as globals until version 16 in 2021, spent its earlier life with Buffer and a pair of small npm shims. And then, in September 2025, the loop closed: Uint8Array.fromBase64, toBase64 and friends landed in Chrome 140, Firefox 133, Safari 18.2 and Node 25, the first time the language itself - not the web platform - got Base64 built in. A format that was forty years old just became a standard library feature of the language, and the next decade of code gets to stop copying helpers around.

Fun Facts

• The fastest "is this even Base64?" test in existence is string.length % 4 === 0. Every valid, padded Base64 string passes; anything else is a stranger.
• atob('') returns ''. The empty string is the only input with no bytes, and it round-trips cleanly through the whole pipeline - no special case needed, ever.
• The WebSocket magic GUID, 258EAFA5-E914-47DA-95CA-C5AB0DC85B11, is a fixed value baked into the RFC, chosen so that a plain HTTP server could never accidentally complete the handshake. It is the most famous constant in protocol engineering that nobody ever generates.
• Chrome and Firefox throw the same exception for the same failure but with different messages. Catch on error.name, not on the message string, or your error handling will have a browser accent.
• A one-megabyte binary string weighs two megabytes in memory, because JavaScript strings are UTF-16: every decoded byte rides along with a byte of unused headroom. The Uint8Array has no such tax.
• "Data URI" is a retired name. The WHATWG renamed it to "data URL" as part of the great URI-to-URL harmonization, which is why you will meet both spellings in specs, posts, and package names.
• RFC 4648 ships a table of test vectors - "M", "Ma", "Man", "Mand" and friends, each with its known encoding - that decoder authors have been checking against for twenty years. If your decoder passes those rows, it is almost certainly correct.
• The most produced Base64 string in the history of computing is almost certainly aGVsbG8=, the encoding of "hello". Every "get started" tutorial, test suite, and stack overflow answer on the planet contributes its vote.

Wrapping Up

So the whole craft of decoding in the browser fits on one page: atob() for the quick, forgiving, universal decode; TextDecoder for turning the bytes into the words you actually want, with fatal: true when the data matters; and Uint8Array.fromBase64 for the modern, strict, fast path that skips the string entirely. In between, the variants have names and rules: base64url for anything that travels in a URL, padding that may or may not be there, whitespace that the old decoder quietly eats. And underneath it all, two attitudes: the bytes are not the text, and the text is not the secret. Decode on purpose, verify before you trust, and when the channel allows it, skip Base64 and take the bytes.

The other half of the journey - taking your bytes and text and turning them into the printable string that all of this started with - is covered in detail in the companion guide to Base64 encoding in JavaScript, linked below.

Last updated: 2026-08-29

Related article: Base64 Encoding in JavaScript/Browser: A Complete Guide