Encode & Decode Base64, JWT, URL & HTML Online Free — Developer Tools Guide

Base64 Encoding and Decoding

What Is Base64?

Base64 is a binary-to-text encoding scheme that converts binary data into a string of 64 ASCII characters (A-Z, a-z, 0-9, +, /, and = for padding). It exists because many systems — email, JSON, URLs — can only handle text safely, not raw bytes.

When you Base64-encode a file, you're not encrypting it. You're not compressing it. You're translating it into a format that text-based protocols can carry without corrupting it. The output is roughly 33% larger than the input.

When to Use Base64

• Embedding images in HTML/CSS: Data URIs use Base64 to inline small images directly into markup, avoiding an extra HTTP request.
• Sending binary data in JSON: JSON has no binary type. If you need to include a file, a signature, or encrypted bytes in a JSON payload, Base64 is the standard approach.
• Email attachments: MIME encoding uses Base64 under the hood to attach files to emails.
• Basic HTTP authentication: The Authorization: Basic header encodes username:password in Base64 (which is why Basic auth without HTTPS is dangerously insecure — it's not encrypted, just encoded).

Base64 in Code

JavaScript / Node.js:

Python:

Go:

Common Base64 Mistakes

Treating it as encryption. Base64 is reversible by anyone. Never use it to "hide" sensitive data. I've seen API keys, passwords, and private certificates stored in Base64 with comments like "encrypted for security." They weren't.

Double encoding. If your framework already Base64-encodes a value and you encode it again, you'll get a valid Base64 string that decodes to... another Base64 string. This happens more often than you'd think, especially with file upload handlers.

Ignoring URL-safe variants. Standard Base64 uses + and /, which have special meanings in URLs. If you're putting Base64 in a URL, use the URL-safe variant (- and _ instead). Most languages have a built-in function for this.

Need to quickly encode or decode Base64 without writing code? The Base64 encoder/decoder on akousa.net handles text and file conversions instantly in your browser. For images specifically, the Image to Base64 converter generates ready-to-use data URIs.

JWT (JSON Web Token) Decoding

What Is a JWT?

A JSON Web Token is a compact, URL-safe way to represent claims between two parties. It's the dominant format for authentication tokens in modern web applications. A JWT has three parts separated by dots:

Each part is Base64URL-encoded JSON:

1. Header — the algorithm used to sign the token (e.g., HS256, RS256).
2. Payload — the claims: user ID, roles, expiration time, issuer, and any custom data.
3. Signature — a cryptographic hash that proves the header and payload haven't been tampered with.

The critical thing to understand: the payload is not encrypted. Anyone can decode the payload and read its contents. The signature only guarantees integrity — that the data hasn't been modified — not confidentiality. Don't put sensitive information (passwords, credit card numbers, SSNs) in JWT payloads.

When to Decode JWTs

• Debugging authentication failures: Is the token expired? Was it issued for the wrong audience? Is the sub claim what you expect?
• Inspecting API responses: Many OAuth providers return JWTs as access tokens or ID tokens. Decoding them reveals scopes, permissions, and provider-specific claims.
• Security auditing: Check what data your application is exposing in tokens. I've found full email addresses, phone numbers, and internal user IDs in tokens that were stored in browser localStorage.
• Troubleshooting clock skew: If your server rejects tokens that should be valid, decode the token and compare the iat (issued at) and exp (expiration) timestamps with your server's clock.

Decoding a JWT in Code

JavaScript:

Python:

Important: Decoding is not the same as verification. Never trust a decoded JWT payload without verifying the signature against your secret or public key. Decoding tells you what the token says. Verification tells you whether to believe it.

For quick inspection during development, the JWT Decoder on akousa.net breaks down the header, payload, and signature visually, shows expiration status, and formats timestamps into human-readable dates. The JWT Inspector goes deeper with claim validation and structure analysis. If you need to generate test tokens, the JWT Generator lets you build them with custom claims.

URL Encoding (Percent Encoding)

What Is URL Encoding?

URLs can only contain a specific set of characters defined in RFC 3986. When a URL needs to include characters outside that set — spaces, ampersands, equals signs, Unicode characters, or anything that could be misinterpreted as a URL delimiter — those characters must be percent-encoded: replaced with a % followed by their hexadecimal byte value.

When You Need URL Encoding

• Query parameters: If a search query contains & or =, it'll break the URL structure unless encoded. ?q=salt & pepper becomes ?q=salt%20%26%20pepper.
• Path segments: File names or identifiers with spaces or special characters need encoding in the URL path.
• Form submissions: Browsers automatically URL-encode form data sent with application/x-www-form-urlencoded content type.
• API requests: When constructing URLs programmatically, any dynamic value must be encoded before being inserted into the URL.

URL Encoding in Code

JavaScript:

Python:

Java:

The Classic URL Encoding Bug

The most common mistake is encoding an entire URL instead of just the dynamic parts. If you pass https://example.com/search?q=test through encodeURIComponent(), you'll get https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dtest — a completely broken URL. Use encodeURIComponent() for individual parameter values, and encodeURI() (or just don't encode) for the full URL structure.

Another frequent issue: double encoding. Your framework encodes the value, then you encode it again. The % from the first encoding gets encoded to %25, and now %20 becomes %2520. If you see %25 in your URLs, you've almost certainly double-encoded something.

The URL Encoder tool on akousa.net lets you encode and decode URL components instantly, which is especially handy when you're debugging a URL with multiple layers of encoding and need to peel them apart one at a time.

HTML Entity Encoding

What Is HTML Entity Encoding?

HTML entity encoding replaces characters that have special meaning in HTML with named or numeric references. The most important ones:

This exists for two reasons: correctness (so the browser doesn't interpret your data as HTML tags) and security (so attackers can't inject scripts into your page).

When to Use HTML Entity Encoding

• Displaying user-generated content: Any text that comes from a user — comments, profile names, search queries — must be entity-encoded before being rendered in HTML. Without it, a user whose name is <script>alert('xss')</script> can execute JavaScript in every other user's browser.
• Preventing XSS (Cross-Site Scripting): HTML entity encoding is the first line of defense against XSS attacks. Modern frameworks like React, Vue, and Angular encode by default, but if you ever use dangerouslySetInnerHTML, v-html, or [innerHTML], you're bypassing that protection.
• Embedding data in HTML attributes: If a value contains quotes, it'll break out of an attribute boundary. <input value="user's "data""> is malformed. Encoding fixes it: <input value="user&#39;s &quot;data&quot;">.
• Email templates: HTML emails often need entity encoding for special characters to render correctly across email clients.

HTML Entity Encoding in Code

JavaScript (browser):

Python:

PHP:

The Security Angle

HTML entity encoding is the difference between a secure application and a headline-making data breach. XSS consistently ranks in the OWASP Top 10, and the root cause is almost always "user input was rendered without encoding."

The rule is simple: encode on output, not on input. Store the raw data in your database. Encode it at the moment you render it in HTML. This gives you flexibility — the same data might be rendered in HTML, in a JSON API response, or in a PDF, and each context needs different encoding.

The HTML Entity Encoder on akousa.net handles both encoding and decoding, which is useful when you're inspecting HTML source code that's been entity-encoded and you need to read the original content.

Comparison Table: Which Encoding When?

When Encoding Types Interact

In real applications, these encoding types often appear together. Understanding how they stack is essential for debugging.

JWT in a URL parameter: A JWT is already Base64URL-encoded. If you put it in a URL query parameter, you typically don't need to URL-encode it again — the Base64URL alphabet was designed to be URL-safe. But if you're putting it in a form field that gets URL-encoded on submission, the dots in the JWT will survive (dots are unreserved in URLs), so it still works.

Base64 in a URL: Standard Base64 uses + and /, which have meaning in URLs. Either use URL-safe Base64 (- and _), or URL-encode the standard Base64 string. Don't just hope it works — it won't.

HTML containing URLs with encoded parameters: Consider an anchor tag with a URL that has encoded query parameters:

The %26 is a URL-encoded &. The browser will URL-decode it when following the link. But if this HTML was generated by server-side code, the & in the href attribute should technically be & for valid HTML:

This is the kind of layered encoding that causes subtle bugs. Having reliable tools to peel apart each layer makes debugging tractable. The developer tools suite on akousa.net includes all four encoding types, so you can chain them: decode the HTML entities first, then URL-decode the result, then Base64-decode the inner value.

Best Practices for Encoding in Production

1. Encode at the boundary. Don't encode data when you receive it. Encode it when you output it, and use the encoding appropriate for the output context (HTML, URL, JSON, etc.).

2. Use framework defaults. React escapes JSX content by default. Django auto-escapes templates. Rails escapes ERB output. Don't disable these features unless you have a specific, well-understood reason.

3. Never use Base64 for security. It's encoding, not encryption. If you need to protect data, use AES-256-GCM or a similar authenticated encryption scheme.

4. Validate JWTs on the server. Decode the payload for display purposes, but always verify the signature before trusting the claims. Use a well-maintained library — don't write your own JWT verification.

5. Test with adversarial inputs. Put <script>, '; DROP TABLE, ../../etc/passwd, and emoji in every input field. If your encoding is correct, none of these will cause problems.

6. Use URL-safe Base64 when the output goes in a URL. Standard Base64 with + and / will break. Every language has a URL-safe variant — use it.

Frequently Asked Questions

Is Base64 encoding the same as encryption?

No. Base64 encoding is completely reversible by anyone without any key or secret. It is a binary-to-text conversion, not a security mechanism. If you need to protect data, use proper encryption algorithms like AES-256-GCM. Base64 should only be used to transport binary data through text-based channels like JSON, HTML, or email.

Can I decode a JWT without knowing the secret key?

Yes, you can decode the header and payload of any JWT without the secret key, because they are simply Base64URL-encoded JSON. The secret key is only needed to verify the signature — to confirm that the token hasn't been tampered with. This is why you should never put sensitive information (passwords, credit card numbers) in JWT payloads. Tools like the JWT Decoder on akousa.net can decode any JWT instantly.

What is the difference between encodeURI() and encodeURIComponent() in JavaScript?

encodeURI() encodes a complete URI and preserves characters that have structural meaning in URLs (:, /, ?, #, &, =). encodeURIComponent() encodes everything except unreserved characters, making it suitable for encoding individual parameter values. Use encodeURIComponent() for values you're inserting into a query string, and encodeURI() only when you need to encode an entire URL while preserving its structure.

Why do I see %2520 in my URLs?

%2520 means a space character has been URL-encoded twice. The first encoding turns the space into %20. The second encoding turns the % into %25, resulting in %2520. This happens when your code URL-encodes a value, and then the framework or HTTP client encodes it again. The fix is to encode only once, usually by letting the framework handle the encoding or by encoding manually — but not both.

Is HTML entity encoding enough to prevent XSS attacks?

HTML entity encoding is the primary defense against XSS when rendering user input in HTML body content. However, it's not sufficient for all contexts. If you're inserting user input into JavaScript code, CSS, URL attributes (href, src), or event handler attributes (onclick), you need context-specific encoding or sanitization. A defense-in-depth approach combines output encoding, Content Security Policy (CSP) headers, and input validation.

Wrapping Up

Encoding and decoding are not exciting topics, but they're foundational. Every web application you build will need at least two of these encoding types, and most will need all four. Understanding what each one does — and critically, what it doesn't do — saves hours of debugging and prevents security vulnerabilities.

When you need to quickly encode or decode something during development, bookmark the developer tools on akousa.net. The Base64 tool, JWT Decoder, URL Encoder, and HTML Entity Encoder all run entirely in your browser — your data never leaves your machine.