Encoding and Decoding Tools: Move Text Safely Between Systems

Encoding and decoding tools convert text between representations so it survives transport through systems that would otherwise corrupt it. This category collects a full set of tools covering Base64, URL encoding, HTML entities, UTF-8, internationalized domain names, hexadecimal, and Morse code.

One thing is worth stating before anything else, because misunderstanding it causes real security incidents: encoding is not encryption. Encoded data is reversible by anyone who receives it, with no key and no secret involved. That is the entire point. If you ever find yourself thinking that Base64 will keep something confidential, stop and use actual cryptography instead.

The tools divide into two families that solve different problems. Character encodings such as UTF-8 answer the question of how a character becomes bytes, which arises because writing systems contain far more characters than a byte can represent. Transport encodings such as Base64 and percent-encoding answer a different question: how data containing a protocol reserved characters travels through that protocol without breaking it. Knowing which family a problem belongs to usually identifies the fix.

Every tool here runs entirely in your browser. Nothing you paste is uploaded, logged, or stored, which matters because these utilities routinely handle tokens, credentials, and API payloads during debugging.

Base64: Binary Data as Text

The Base64 encoder and Base64 decoder handle the most widely used binary-to-text encoding on the web.

Base64 exists because many systems were designed to carry text and mishandle arbitrary binary data. Email, JSON, XML, and URLs all have characters with special meaning, and raw binary containing those bytes breaks them. Base64 represents every three bytes of input as four ASCII characters drawn from a 64-character alphabet of letters, digits, plus, and slash, with equals signs padding the end.

The size cost is roughly 33 percent. Four output characters for every three input bytes is the fixed overhead, and it is the trade you accept for the ability to embed binary anywhere text is allowed. This is why inlining a small icon as a data URI is usually worthwhile and inlining a large photograph is usually not.

Base64url is a distinct variant. Standard Base64 uses plus and slash, both of which have meaning in URLs. Base64url substitutes hyphen and underscore and typically omits padding. JSON Web Tokens use this variant, which is why pasting a JWT segment into a standard Base64 decoder sometimes fails or produces garbage.

Common failure modes are worth recognizing. Incorrect padding causes decode errors, since the length must be a multiple of four. Whitespace and line breaks introduced by copying from an email header or a wrapped log line break decoding unless stripped. And decoding succeeds while producing nonsense when the input was Base64url and the decoder expected standard Base64.

URL Encoding: Percent-Encoding for the Web

The URL encoder, URL decoder, and combined URL encoder and decoder handle percent-encoding, defined in RFC 3986.

URLs have a restricted character set, and several characters carry structural meaning: the question mark begins a query string, the ampersand separates parameters, the equals sign assigns values, the hash introduces a fragment, and the slash delimits path segments. When any of these appears in data rather than structure, it must be percent-encoded as a byte value preceded by a percent sign.

The space character is the most familiar case, encoded as %20 in paths and often as a plus sign in query strings, a legacy of HTML form submission that continues to cause confusion. A literal plus sign in query data must therefore itself be encoded as %2B, or it will be read as a space.

Double encoding is the classic bug. If already-encoded data is encoded again, the percent signs are themselves encoded, so %20 becomes %2520. The result is a URL that looks approximately right and resolves to the wrong thing, or to nothing. This typically happens when two layers of code both helpfully encode the same value, and the fix is to establish which layer owns encoding rather than adding a decode step.

Encoding context matters. The rules differ between a path segment, a query parameter, and a fragment, which is why some languages provide separate functions for each. Using a whole-URL encoder on a component, or a component encoder on a whole URL, produces subtly wrong results in both directions.

HTML Entities: Escaping Markup

The text to HTML entities converter and HTML entities to text converter handle escaping for web content.

Certain characters carry structural meaning in HTML. The less-than sign opens a tag, the ampersand begins an entity reference, and quotation marks delimit attribute values. Displaying these literally requires replacing them with entity references such as the named forms for ampersand, less-than, and greater-than, or numeric references.

This is a security control, not a formatting nicety.Failing to escape user-supplied content before rendering it as HTML is the mechanism behind cross-site scripting. If a user can submit a script tag that reaches another user's browser unescaped, it executes with that user's session. Escaping on output is the standard defence, and it must happen at render time in the correct context rather than on input, since the same value may be safe in one context and dangerous in another.

Double encoding shows up here too. Content escaped once and then escaped again displays the entity code as literal text, so a reader sees the escape sequence rather than the character. This commonly happens when a content management system escapes content that arrived already escaped, and it is the cause of visible ampersand-hash sequences on published pages.

UTF-8 and Character Encoding

The UTF-8 encoder and UTF-8 decoder convert between characters and their byte representations.

Unicode assigns a code point to every character across every writing system. An encoding determines how those code points become bytes. UTF-8 uses a single byte for ASCII characters, keeping English text compact and backward compatible with older systems, and two to four bytes for everything else. It is now the overwhelming majority of web content and the sensible default for essentially everything.

Mojibake is what an encoding mismatch looks like. When UTF-8 bytes are interpreted as Latin-1 or Windows-1252, each byte of a multi-byte character renders separately, so a single curly apostrophe becomes several strange symbols. The underlying data is usually intact and only the interpretation is wrong, which means it is frequently recoverable once you identify what happened.

Replacement characters mean data was lost. A black diamond containing a question mark, or a bare question mark where a letter belongs, indicates the system could not represent the character and substituted a placeholder. Unlike mojibake, this is generally unrecoverable, because the original value was discarded rather than misread.

Byte order marks cause parse failures. A BOM at the start of a file is invisible in editors but unexpected by many parsers, producing errors that point at position zero in a file that looks perfect. UTF-8 does not require a BOM, and including one causes more problems than it solves.

Internationalized Domain Names

The IDN encoder and IDN decoder convert between Unicode domain names and their Punycode representation.

The domain name system was designed for a limited ASCII character set, so domains containing accented letters, Cyrillic, Arabic, Chinese, or emoji need a representation DNS can carry. Punycode encodes Unicode domain labels into ASCII strings prefixed with xn--, which is why a domain that displays in one script appears in browser tooling and certificate details as a string of seemingly random characters.

The homograph attack is the security concern here. Many characters across different scripts are visually identical or near-identical to Latin letters. A Cyrillic letter that renders exactly like a Latin one allows registration of a domain visually indistinguishable from a legitimate site while being an entirely different address. Browsers mitigate this by displaying Punycode rather than Unicode when a label mixes scripts suspiciously, but the defence is imperfect. Decoding a domain to see its actual Punycode form is a genuine verification step when something looks off.

Hexadecimal and Morse

The text to hex converter represents characters as their hexadecimal byte values. Hexadecimal is convenient because one hex digit maps exactly to four bits, so each byte is precisely two digits, making the relationship between the representation and the underlying data direct in a way decimal is not. It is the standard way to display hashes, colour values, memory contents, and binary data under inspection.

The text to Morse code converter and Morse code translator handle a rather older encoding. Morse represents letters as sequences of short and long signals, with code length inversely related to letter frequency in English, which is why E is a single dot and Q takes four symbols. That frequency weighting is an early example of the compression principle underlying modern encoding schemes. Morse remains in use in amateur radio and aviation navigation beacons, and it is one of very few encodings transmissible by sound, light, or touch.

Data URIs and Where Base64 Appears

Base64 turns up in more places than most people realize, and recognizing it saves debugging time.

Data URIs embed a resource directly in a document rather than referencing an external file. The format states a MIME type, declares base64 encoding, and follows with the encoded payload. They are common for small icons in CSS, inline SVG, and email images, and they eliminate an HTTP request at the cost of size and cacheability.

HTTP Basic authentication transmits credentials as Base64 in an Authorization header. This is worth understanding precisely because it looks like protection and is not: the credentials are recoverable by anyone who sees the header. Basic auth is only acceptable over HTTPS, where the transport layer provides the confidentiality the encoding does not.

Email attachments use Base64 because SMTP was designed for seven-bit ASCII text. Any binary attachment is encoded, which is why raw email source contains long blocks of apparently random characters and why attachments inflate message size.

JSON Web Tokens use Base64url for their header and payload segments. The significant consequence is that a JWT payload is encoded, not encrypted, so anyone holding the token can read every claim inside it. Sensitive data must never be placed there on the assumption it is hidden.

Certificates and keys in PEM format are Base64-encoded binary wrapped in begin and end markers. This is why a certificate file is readable text that means nothing to a human reader.

Configuration and secret storage frequently Base64-encodes values, notably in Kubernetes secrets. This is a serialization convenience, not a security measure, and treating Base64-encoded secrets as protected is a common and consequential misunderstanding.

Encoding in APIs and Data Exchange

Most encoding problems surface at boundaries between systems, and a few patterns account for the majority of them.

Query strings versus request bodies. Data in a query string must be percent-encoded and is subject to URL length limits that vary by server and proxy. Data in a request body has no such constraint and is not exposed in server logs or browser history, which is why anything sensitive or lengthy belongs in the body.

Content-Type declarations must match reality. A response declaring one character set while containing another produces mojibake regardless of how carefully the data was encoded. The declaration is what the receiving system trusts, so an incorrect header defeats correct encoding entirely.

Form encoding has two common variants. Standard form submission percent-encodes fields and is unsuitable for binary. Multipart form data separates fields with boundary markers and carries binary without encoding overhead, which is why file uploads use it.

Nested encoding accumulates. A value that is Base64-encoded, placed in JSON, and then put in a URL has been encoded three times, and each layer must be reversed in the correct order. Confusion about the order is a frequent source of values that decode to nonsense rather than failing cleanly.

Signatures must be computed over the right bytes. When verifying a webhook signature, hash the raw request body rather than a re-serialized version. Any whitespace or key ordering difference introduced by parsing and re-encoding changes the hash and causes verification to fail for reasons that look mysterious.

Choosing the Right Encoding

Use Base64 when embedding binary data in a text format: images in CSS or HTML, file attachments in JSON, or binary payloads in email.

Use URL encoding for anything placed into a URL path, query string, or fragment, and be careful to encode components rather than whole URLs.

Use HTML entity encoding when rendering untrusted content as HTML, always at output time and always in the correct context.

Use UTF-8 as the default character encoding for everything, and declare it explicitly in HTTP headers, HTML meta tags, and database configuration rather than relying on defaults.

Use none of them for secrets. Encoding provides no confidentiality. Credentials, tokens, and personal data require encryption in transit and at rest, and access control on top. If the reason you are encoding something is that you do not want someone to read it, you have chosen the wrong tool entirely and should reach for real cryptography instead of an encoding.

Why Encoding Exists: A Short History

The reason so many encodings exist, and why they interact awkwardly, is largely historical.

ASCII established the assumption. Standardized in the 1960s with 128 characters in seven bits, it covered English and little else. For decades a character and a byte were effectively the same thing, and enormous amounts of software were written assuming that identity held. Much of the friction today comes from that assumption being embedded in systems that outlived it.

Code pages fragmented the eighth bit. When the spare bit became available, different regions filled those 128 additional slots differently. Latin-1 covered Western European languages, other pages covered Cyrillic, Greek, and Hebrew, and the same byte meant different characters depending on which page was assumed. A document was only readable if the reader knew which page applied, and nothing in the file said so.

Unicode unified the character set. Rather than competing regional standards, one code point per character across every writing system. The remaining question was how to turn those code points into bytes, which is what an encoding does.

UTF-8 won on backward compatibility. Competing encodings such as UTF-16 use two bytes minimum, breaking every system that assumed ASCII. UTF-8 keeps ASCII characters as single identical bytes, so existing English text and existing software kept working while everything else became representable. That pragmatism is why it now dominates.

Transport encodings solved a different problem. Base64 and percent-encoding exist not because of character sets but because protocols reserved certain bytes for structure. Email, URLs, and markup all needed a way to carry data containing their own delimiters, and that need is independent of Unicode entirely.

Encoding and Search Visibility

Encoding choices affect how content is indexed, which is worth knowing if the pages matter for search.

Mojibake damages indexing directly. Garbled characters mean search engines see different words than you intended. A keyword containing a corrupted apostrophe is not the keyword you are trying to rank for, and the damage is invisible in any view that renders the text correctly.

URL encoding affects readability and click-through. A URL heavy with percent sequences is harder to read in results and less likely to be clicked or shared. Using ASCII-friendly slugs rather than encoded non-ASCII characters generally produces cleaner links, though this trades against using the natural language of the audience.

Internationalized domains display inconsistently. Some contexts show the Unicode form and others show Punycode, so a domain intended to read naturally in one script may appear as an xn-- string in search results, browser address bars, or link previews depending on the client.

Declared and actual encoding must agree. A page declaring one charset while serving another can render correctly in a forgiving browser and be indexed incorrectly by a crawler that trusts the declaration, which is a failure mode that survives casual checking.

Related Tool Categories

For JSON, YAML, XML, and Markdown conversion, see the data format converters. For hashing, JWT decoding, and other developer utilities, see the developer tools. For invisible characters and whitespace problems, see the text tools. The full tool directory is searchable.