Encoders Tools
Encode and decode data in various formats. Work with JWT tokens, Markdown, and text encodings.
Encoding and decoding is how data travels between systems. These tools handle JWT, Markdown, HTML, and text encodings like hex and binary - inspect tokens, preview markup, and convert formats without sending data anywhere.
5 tools availableEncoding is a contract about the wire, not about the text
An encoder makes bytes survive a trip through a system that was not designed for them. Each format here decides something slightly different about what may appear where, and those differences are where defects hide.
A JWT is three base64url parts, and its claims have types
RFC 7519 is explicit about the shape: "A JWT is represented as a sequence of URL-safe parts separated by period ('.') characters. Each part contains a base64url-encoded value." That is what lets a token sit in an Authorization header or a query string without further escaping - and why decoding is a two-step job: split on the periods, then base64url-decode each part in order.
The claims carry types as well as values. The exp claim "identifies the expiration time on or after which the JWT MUST NOT be accepted for processing", and "Its value MUST be a number containing a NumericDate value" - a NumericDate being "a JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds". An expiry encoded as a string is not a stylistic choice; it fails the type the claim requires. Honour the clock-skew allowance too: "Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew."
Hex, Markdown and HTML entities answer different questions
RFC 4648 section 8 defines the simplest of them: "Base 16 encoding is the standard case-insensitive hex encoding and may be referred to as 'base16' or 'hex'", using "A 16-character subset of US-ASCII ... enabling 4 bits to be represented per printable character" - which is exactly why hex doubles a payload's size.
Markdown escaping is narrower than it looks. In CommonMark "A backslash at the end of the line is a hard line break", but "Backslash escapes do not work in code blocks, code spans, autolinks, or raw HTML" - so a character that renders correctly in a preview can reach the renderer as literal text. HTML draws the boundary differently again: in escapable raw text elements the content "can have text and character references, but the text must not contain an ambiguous ampersand".
| Encoding | What it guarantees | Where it breaks | Specification |
|---|---|---|---|
| Base16 (hex) | 4 bits per printable character; case-insensitive | doubles the byte count; no padding step to get wrong | RFC 4648, section 8 |
| Base64url (JWT parts) | an alphabet that is safe in URLs and headers | decode order matters: split on periods before decoding | RFC 7519, section 3 |
| Markdown escapes | suppress markup in normal text | ignored inside code spans, code blocks, autolinks and raw HTML | CommonMark specification |
| HTML character references | one code point per reference | an ambiguous ampersand is not decoded at all | WHATWG HTML, character references |
Decode a token before trusting it with the JWT Decoder, build a test token that exercises the type rules with the JWT Builder, check how your markup actually renders in the Markdown Preview, convert between markup forms with HTML to Markdown, and inspect raw bytes with the Text Encoder.
Sources: RFC 7519, JSON Web Token (JWT), sections 2 and 4.1; RFC 4648, section 8 Base 16 Encoding; CommonMark specification 0.31.2; WHATWG HTML Standard, the HTML syntax.