Understand Base64, URL Encoding, and HTML Entities Without Treating Them as Encryption

Base64, percent encoding, and HTML entities solve different representation problems. They do not encrypt a message, verify who created it, validate an input, or make a value safe in every context. First identify where the value will be read: a byte-oriented field, one URL component, or HTML displayed as text.

Keep the original value until the receiving system has accepted and correctly displayed the transformed value. A string can be syntactically valid after conversion while still being wrong for its destination because it was encoded at the wrong layer or encoded twice.

Zoom image

Base64 changes the representation of UTF-8 bytes; it does not conceal the source text.

Base64 maps bytes to a limited ASCII character set. This text tool encodes Unicode input as UTF-8 bytes and then Base64; decoding reverses that process for valid UTF-8 Base64. It is useful when a text-only format must carry a byte sequence, but it usually increases size and is easy for anyone with the value to reverse.

Do not put credentials, private information, or access tokens in Base64 and call them protected. Use the encryption and access-control mechanism required by the system instead. When interoperability matters, preserve the exact value and padding the other side expects; standard Base64 and URL-safe Base64 are not always interchangeable.

Zoom image

A round trip confirms the representation, not confidentiality or authorization.

A query value such as a search term may contain spaces, ampersands, equals signs, Unicode, or a literal percent. Encode that value as a component before joining it to the query string. This prevents `&` or `=` inside the value from becoming URL structure. For example, encode a value first, then place it after `?q=` rather than applying component encoding to an already complete URL.

Use full-URL encoding only when you intentionally want to preserve delimiters such as `://`, `?`, `&`, `=`, and `#`. Do not blindly decode an entire URL, and do not decode repeatedly: an escaped percent sign can become an escape sequence after one pass. Let the framework or URL API construct parameters where possible, then test a value containing spaces, non-ASCII text, `&`, `=`, and `%`.

Zoom image

Ampersands, equals signs, spaces, Unicode, and percent signs stay inside the value.

HTML entity encoding is for displaying special characters as text. This tool converts `&`, `<`, `>`, double quote, single quote, and backtick to entities, then can decode recognized entities. That is useful for showing a code sample or literal text in HTML, but it is not a general sanitizer for arbitrary markup.

Output safety is context-specific. Text nodes, quoted attributes, unquoted attributes, URLs, CSS, and JavaScript each have different rules. Prefer framework template escaping and DOM APIs over string construction. Never treat a generic entity encoder as permission to insert untrusted content through HTML injection APIs; use a deliberate, reviewed sanitization policy if you genuinely need to allow a limited subset of markup.

Zoom image

Entity encoding is useful for displaying literal text, not for broadly sanitizing markup.

Start with a disposable sample that contains ordinary text, Unicode, spaces, `&`, `=`, `%`, quotes, and angle brackets. Encode it once for the intended destination, send it through the same path your application uses, decode or render it there, and compare the result with the original. Check that no parameter was split, no text was changed, and nothing was interpreted as markup.

These three MV Tools converters run in the browser: input, result, copying, and data-URL download are not uploaded to MV Tools. Local processing is not a reason to paste sensitive production values into a browser session. Prefer redacted samples, protect signed URLs and tokens, and keep the source of record in the system that owns it.

Zoom image

Use framework escaping and DOM APIs for the actual output context.