Base64, URL and HTML Encoder / Decoder
Convert text between Base64, percent-encoding and HTML entities in both directions.
Free and instant — results appear in seconds. No sign-up, no limits, and nothing you type is stored.
Three different encodings solving three different transport problems. None of them is encryption, and treating any of them as such is a recurring security mistake.
Three encodings, one string
The string a+b=c & d<e:
Base64 YStiPWMgJiBkPGU=
URL encoded a%2Bb%3Dc%20%26%20d%3Ce
HTML encoded a+b=c & d<eEach targets a different problem.
Base64 turns arbitrary bytes into 64 safe ASCII characters so binary data survives a text-only channel — email attachments, data URIs, JSON payloads. It costs about 33% size inflation, since three bytes become four characters. The = padding at the end pads the output to a multiple of four.
URL encoding escapes characters with reserved meaning in a URL. Here + becomes %2B because a raw + means space in a query string, = becomes %3D because it separates key from value, and & becomes %26 because it separates parameters. Skip this and your parameter silently splits into three.
HTML encoding escapes characters with meaning in markup. Only & and < needed changing. Missing this is how user input becomes an XSS vulnerability.
Note that Base64 is trivially reversible. Anyone can decode it in a second. It provides no confidentiality whatsoever.
Base64 is not encryption
Worth repeating because the mistake is common and consequential. Base64 is an encoding — a reversible representation change with no key involved. Credentials "protected" by Base64 are plaintext with an extra step.
HTTP Basic authentication sends Base64-encoded credentials, which is precisely why it is only acceptable over TLS.
URL encoding variants
rawurlencode() follows RFC 3986 and encodes a space as %20. urlencode() follows the older form-encoding convention and uses +. This tool uses the former.
The distinction matters in path segments, where a + is a literal plus and not a space. Encoding a filename containing + with the wrong function produces a broken URL.
HTML encoding and XSS
Escaping on output is the defence. Any user-supplied value rendered into a page must be escaped in the context it lands in — HTML body, attribute, JavaScript string and URL each require different treatment.
Escaping on input instead of output is a common mistake: it corrupts stored data and still fails when the same value is rendered into a different context.
Frequently asked questions
Is Base64 encryption?
No. It is a reversible encoding with no key, decodable by anyone in seconds. It provides zero confidentiality. Credentials encoded in Base64 are plaintext with an extra step, which is why HTTP Basic authentication is only safe over TLS.
Why does Base64 make my data larger?
It represents three bytes of input as four ASCII characters, an inflation of about 33 percent. That is the cost of making arbitrary binary data survive a text-only channel such as email or a JSON field.
What is the difference between URL encoding a space as %20 or as +?
The plus form comes from older form encoding and is valid only in query strings. RFC 3986 uses %20, which is correct everywhere including path segments. In a path, a plus is a literal plus character, so using the wrong function breaks URLs containing one.
When do I need HTML encoding?
Whenever user-supplied content is rendered into a page. Escaping on output is what prevents cross-site scripting. Note that the correct escaping differs by context — HTML body, attribute, JavaScript string and URL each need different treatment.
Reviews
No reviews yet. If this tool solved something for you, yours would be the first — and it helps other people decide whether it is worth their time.