Encoding is how computers safely transmit and store data across different systems. This guide covers the three most common web encoding types: Base64 for binary data, URL encoding for query strings, and JWT for authentication tokens.

Tools in This Cluster

• Base64 Encoder/Decoder
• URL Encoder/Decoder
• JWT Decoder

See also our related articles on encoding, security, and web development.

Encoding Guide: Base64, URL Encoding & JWT Tokens

How to Use This Calculator

This encoding calculator handles three essential web development encoding formats: Base64, URL encoding, and JWT tokens. Each serves a different purpose in modern web applications.

For Base64 encoding: Enter your plain text, binary data, or existing Base64 string in the input field. Select "Encode" to convert plain text to Base64, or "Decode" to convert Base64 back to readable text. Base64 is commonly used for encoding images, files, and authentication credentials in web applications.

For URL encoding: Paste any URL or text containing special characters into the input field. Choose "Encode" to convert special characters to their percent-encoded equivalents (like spaces becoming %20), or "Decode" to reverse the process. This ensures URLs work correctly across all browsers and systems.

For JWT tokens: You can either create a new JWT by entering header and payload data, or decode an existing JWT token by pasting it into the input field. The calculator will separate the header, payload, and signature components, displaying each in readable JSON format. Note that this tool focuses on reading JWT structure rather than cryptographic verification.

The calculator processes your input in real-time, showing results immediately as you type. All processing happens in your browser - no data is sent to external servers, ensuring your sensitive information remains private.

How We Calculate This

Base64 Encoding Process: Base64 converts binary data into ASCII text using a 64-character alphabet (A-Z, a-z, 0-9, +, /). The algorithm takes every three bytes (24 bits) of input data and splits them into four 6-bit groups. Each 6-bit group maps to one character in the Base64 alphabet. When the input length isn't divisible by 3, padding characters (=) are added to complete the encoding.

For example, the word "Cat" becomes:

• C = 01000011, a = 01100001, t = 01110100
• Combined: 010000110110000101110100
• Split into 6-bit groups: 010000, 110110, 000101, 110100
• Mapped to Base64: Q, 2, F, 0
• Result: "Q2F0"

URL Encoding Process: URL encoding replaces unsafe characters with a percent sign followed by two hexadecimal digits representing the character's ASCII value. Unsafe characters include spaces, special symbols, and non-ASCII characters that could break URL parsing.

The algorithm examines each character in the input string. Safe characters (A-Z, a-z, 0-9, and a few symbols like hyphens) pass through unchanged. Unsafe characters convert to their hexadecimal ASCII representation prefixed with %. For example, a space (ASCII 32) becomes %20, and an ampersand (ASCII 38) becomes %26.

JWT Token Structure: JWT tokens consist of three Base64-encoded sections separated by dots: header.payload.signature. Our calculator decodes each section independently:

1. The header typically contains the token type ("JWT") and signing algorithm 2. The payload contains the actual data (claims) like user ID, expiration time, and permissions 3. The signature verifies the token's authenticity (not validated by this calculator)

Each section undergoes Base64 decoding to reveal its JSON structure, allowing you to inspect the token's contents without external tools.

What the Results Mean

Base64 Results: Encoded Base64 output appears as a string of letters, numbers, and occasional plus signs or slashes, possibly ending with one or two equals signs for padding. This format safely represents binary data in text-only environments like JSON, XML, or email. Decoded results show the original text or indicate if the input wasn't valid Base64.

The length of Base64-encoded data is approximately 133% of the original size due to the encoding overhead. This expansion is normal and expected - don't worry if your encoded output seems longer than the input.

URL Encoding Results: Encoded URLs show percent-encoded characters (%20 for spaces, %3A for colons, etc.) replacing special characters. This ensures the URL works correctly when copied, pasted, or transmitted across different systems. Decoded results restore the original readable format with all special characters intact.

Pay attention to double-encoding warnings - if you see sequences like %2520, this indicates the URL was encoded multiple times, which can cause problems in web applications.

JWT Token Results: Decoded JWT tokens display three JSON objects representing the header, payload, and signature sections. The header shows technical details about the token format and signing method. The payload contains the actual data, including standard claims like:

• iss (issuer): Who created the token
• sub (subject): Who the token represents
• exp (expiration): When the token expires
• iat (issued at): When the token was created

Custom claims may appear alongside these standard ones. Expiration times display in both Unix timestamp and human-readable formats for convenience.

Tips and Common Mistakes

Base64 Best Practices: Never use Base64 for security - it's encoding, not encryption. Anyone can decode Base64 data instantly. Use Base64 only for data formatting and compatibility, not for hiding sensitive information.

Watch for line breaks and whitespace in Base64 strings, especially when copying from formatted documents. Remove these characters before decoding, as they'll cause errors.

URL Encoding Guidelines: Encode URLs before sending them through systems that might modify special characters, like email clients or messaging platforms. However, avoid double-encoding - don't encode URLs that are already properly encoded.

Space characters cause the most URL problems. Always encode spaces as %20 in URLs, though + symbols work in form data contexts. When in doubt, use %20 for universal compatibility.

JWT Token Considerations: Remember that JWT tokens are not encrypted by default - anyone can read the header and payload contents using tools like this calculator. Never store sensitive data like passwords in JWT payloads.

Check expiration times carefully. Expired tokens won't work for authentication, and the exp claim shows exactly when expiration occurs. Build buffer time into your applications to refresh tokens before they expire.

Be cautious with tokens from unknown sources. While this calculator safely decodes token structure, never use untrusted tokens in production applications without proper signature verification.

FAQ

Q: Is Base64 secure for storing passwords or sensitive data?

A: No, Base64 is not secure for sensitive data. It's simply an encoding format that converts data to a text-friendly format - anyone can decode it instantly without keys or passwords. Base64 provides no security protection whatsoever. For sensitive data, use proper encryption algorithms like AES, not Base64 encoding.

Q: Why do my URLs still break after encoding special characters?

A: This typically happens due to context-specific encoding requirements. Different parts of URLs need different encoding approaches - query parameters, path segments, and fragments each have specific rules. Also, some systems require double-encoding, while others break with double-encoding. Try encoding only the problematic portions of your URL rather than the entire string, and test in your specific environment.

Q: Can I trust JWT tokens that decode successfully in this calculator?

A: Successfully decoding a JWT's structure doesn't mean the token is valid or trustworthy. This calculator only reads the token format - it doesn't verify cryptographic signatures or check expiration times against current time. In production applications, always validate JWT signatures using proper libraries and verify all claims (especially expiration) before trusting the token's contents.