What text encoding actually does

Encoding is the process of mapping characters to a specific byte representation so they can safely travel through systems that only accept a restricted character set. It is not encryption. Anyone who knows the encoding scheme can decode the output — the goal is transport safety, not secrecy.

Each format above solves a different practical problem. Picking the right one matters: the wrong encoding can quietly corrupt data, break URLs, or introduce subtle security bugs like cross-site scripting.

When to use each format

Base64

Base64 represents binary data using 64 printable ASCII characters (A–Z, a–z, 0–9, +, /, with = padding). Use it when you need to embed binary data in a text-only context: images in data URIs, file uploads in JSON payloads, credentials in HTTP Basic auth, or attachments in email MIME bodies. Base64 inflates size by about 33%.

A common variant, Base64URL, swaps + and / for - and _ so the output is safe to drop into URLs or filenames. JWTs use Base64URL, not standard Base64.

URL encoding (percent-encoding)

URL encoding replaces reserved characters with % followed by their two-digit hex byte value. Use it on individual components of a URL — query string values, path segments containing spaces or /, fragments — not on the whole URL at once. For example, the space in hello world becomes %20, and & inside a query value becomes %26 so it isn't mistaken for a parameter separator.

HTML entity encoding

HTML entities escape characters that would otherwise be interpreted as markup: < becomes <, & becomes &, and so on. Anywhere untrusted text gets rendered into an HTML page, it should be entity-encoded first. Failing to do so is the root cause of most stored XSS vulnerabilities.

Hex

Hexadecimal encoding writes each byte as two characters from 0–9 and a–f. You'll see it in hash outputs, memory dumps, binary file inspection, and cryptographic key displays. It doubles the size of the input but is easier for humans to read byte-by-byte than Base64.

Binary

Binary encoding writes each byte as eight 0/1 characters. It's rarely used for real transport (it's 8× larger than the original), but it's useful for teaching, for visualizing bit-level operations, and for low-level debugging.

ROT13

ROT13 rotates each Latin letter by 13 positions: A↔N, B↔O, and so on. It is a trivial substitution cipher, historically used on Usenet to obscure spoilers. It has no security value. Non-letters pass through unchanged.

Common pitfalls

• Base64 is not encryption. Anyone can decode it in one step. Never use Base64 alone to protect credentials or tokens.
• Encode components, not whole URLs. Running encodeURIComponent on an entire URL mangles the :// and ?. Encode each query value individually.
• Entity-encode before rendering, not before storing. Store the raw string; encode at the point of output. That way the same data can render safely in HTML, JSON, or CSV contexts.
• Watch padding. Standard Base64 may end with = or ==. Some implementations strip it; others require it. Base64URL usually omits it.
• Character set confusion. Hex and Base64 require ASCII; feeding them UTF-8 multi-byte sequences works, but round-trip through systems that assume Latin-1 can corrupt non-ASCII text.

FAQ

What a cryptographic hash is

A cryptographic hash is a one-way function that turns any input — a string, a file, a message — into a fixed-length fingerprint. Two properties matter: the same input always produces the same output, and it is computationally infeasible to recover the input from the output or to find two different inputs that hash to the same value (a "collision").

Hashes are used for file integrity checks, digital signatures, content-addressable storage (like Git commit IDs), deduplication, and as a component inside password hashing schemes. They are not encryption — there is no key, and the operation is not reversible.

Picking an algorithm

MD5 and SHA-1 are broken — what does that mean?

Practical collision attacks exist for both. Researchers can produce two different inputs that hash to the same MD5 or SHA-1 digest. That means you cannot trust them when the question is "did this content get tampered with?" or "is this signature authentic?" They are still fine for non-adversarial uses: detecting accidental corruption, sharding data across buckets, or quickly comparing cached values you produced yourself.

Hashing passwords — read this first

For passwords, use an algorithm designed to be deliberately slow and memory-hard:

• Argon2id — the current recommendation (winner of the 2015 Password Hashing Competition).
• bcrypt — well-understood, widely supported, still acceptable.
• scrypt — good option if your language has solid library support.
• PBKDF2 — acceptable where FIPS compliance is required, with a high iteration count (600,000+ for SHA-256 as of NIST SP 800-132 updates).

Every one of these applies a per-user random salt automatically and bundles it into the output string. Never roll your own scheme by concatenating salt and password and running SHA-256 — you'll miss a detail that matters.

Practical uses for the hashes above

• File integrity. Compare the SHA-256 of a download against the one published on the vendor's site to detect corruption or tampering.
• Content addressing. Git commit IDs and IPFS CIDs use hashes so a given piece of content has a deterministic identifier.
• HMAC signatures. Webhook providers (Stripe, GitHub, Slack) sign payloads with HMAC-SHA-256; you verify by recomputing the hash with the shared secret.
• Caching keys. Hash a canonical representation of the inputs to produce a stable cache key.
• Deduplication. Hash chunks of a file to find and skip duplicate blocks in backups or build artifact storage.

FAQ

What is a JSON Web Token?

A JWT is a compact, URL-safe way to represent claims — small pieces of information — transferred between two parties. It's most often used as a bearer token: the client presents it with each request, and the server trusts it because it was signed by an authority the server recognizes.

A JWT is three Base64URL-encoded parts separated by dots:

header.payload.signature

The header says which algorithm was used to sign the token. The payload holds the claims. The signature lets the recipient verify the token wasn't altered.

Standard claims you'll see in the payload

• iss — issuer. Who created this token (e.g. https://auth.example.com).
• sub — subject. Who the token is about, usually a user ID.
• aud — audience. Which service is supposed to accept this token.
• exp — expiration time, as a Unix timestamp. The token is invalid after this.
• nbf — not-before. The token is invalid before this timestamp.
• iat — issued at. When the token was created.
• jti — JWT ID. A unique identifier, useful for revocation tracking.

Anything else is a custom claim: email, roles, tenant_id, or whatever your system needs. Keep custom claims small — every request has to carry them.

Signing algorithms

The header's alg field picks the signing scheme. The three common choices:

• HS256 (HMAC-SHA-256) — symmetric. Issuer and verifier share one secret key. Simple, fast, but everyone who can verify can also forge tokens.
• RS256 (RSA-SHA-256) — asymmetric. Issuer signs with a private key; anyone can verify with the public key. Right choice when third parties need to validate tokens.
• ES256 (ECDSA with P-256) — asymmetric, like RS256 but with smaller keys and shorter signatures. A good default if your library supports it.

Common JWT mistakes

• Trusting the decoded payload without verifying the signature. Anyone can produce a Base64URL string that decodes to anything. The signature is what makes the content trustworthy. This decoder inspects only — your server must verify.
• Storing JWTs in localStorage. Accessible to any JavaScript running on the page, so a single XSS bug exposes every user's token. Prefer an HTTP-only, Secure, SameSite cookie.
• Long-lived access tokens. Once issued, a JWT can't be revoked without extra infrastructure. Use short lifetimes (minutes, not days) and rotate with a separate refresh mechanism.
• Putting sensitive data in the payload. JWTs are signed, not encrypted. The payload is readable by anyone who has the token. For encrypted tokens, use JWE (JSON Web Encryption).
• Skipping aud validation. If you issue tokens for multiple services, a token meant for service A should not be accepted by service B.
• Clock skew. Allow a small leeway (30–60 seconds) when checking exp and nbf so tokens issued near expiry don't fail across slightly out-of-sync machines.

FAQ

JSON in one paragraph

JSON (JavaScript Object Notation) is a plain-text format for structured data, originally derived from a subset of JavaScript object literal syntax. A JSON document is one value: an object ({...}), an array ([...]), a string, a number, true, false, or null. It became the dominant interchange format for web APIs because it's easy to read, easy to generate, and supported in every language out of the box.

Strict syntax rules

JSON looks like JavaScript but it's strictly smaller. These rules trip up most people:

• Keys must be double-quoted strings. {name: "ada"} is valid JavaScript but invalid JSON. It must be {"name": "ada"}.
• Only double quotes. Single-quoted strings are not JSON.
• No trailing commas. [1, 2, 3,] is invalid. ECMAScript allows them; JSON does not.
• No comments. Neither // nor /* */. If you want comments, use JSONC or JSON5 — but those are different formats and most strict parsers will reject them.
• Numbers are decimal only. No 0x hex, no leading +, no trailing decimals like 1., no NaN or Infinity.
• Strings are UTF-8 sequences of characters, with \n, \t, \", \\, \uXXXX and a few other escapes.

The precision trap with numbers

JSON numbers have no size limit in the spec, but most implementations parse them into a 64-bit float. That means any integer larger than 253 − 1 (9007199254740991) can quietly lose precision.

JSON.parse('{"id": 9007199254740993}')
// { id: 9007199254740992 }  // off by one — silent corruption

If your API returns big IDs (Twitter snowflake IDs, database bigints, blockchain amounts), serialize them as strings, not numbers. On the client, parse into a BigInt or leave as a string. This is a real production bug, not a theoretical one.

Pretty-print vs. minify

• Pretty-print adds indentation and newlines. Use it for debugging, log output, and anything a human will read.
• Minify strips all optional whitespace so the payload is as small as possible. Use it for transport. The two representations are semantically identical — parsing either produces the same structure.

Common JSON errors you'll see

• Unexpected token } in JSON at position N — usually a stray trailing comma before the closing brace.
• Unexpected token ' in JSON — single quotes around a key or value. Switch to double quotes.
• Unexpected end of JSON input — the string is truncated. Check that you copied the whole payload, and watch for responses that cut off due to content-length or gzip issues.
• Unexpected non-whitespace character after JSON — two JSON values concatenated, or trailing debug output. Some APIs prefix output with )]}' as an anti-hijacking measure; strip that line before parsing.

FAQ

Regex, in less than you'd think

A regular expression is a pattern describing a set of strings. The pattern is matched against a target string, and depending on how you use it, you get either a yes/no answer, a list of matches, or the string with substitutions applied. This tester uses the JavaScript regex engine — the same one you'll use in Node and in browsers — so the syntax you learn here is the syntax you'll ship.

The building blocks

Literals and metacharacters

Most characters match themselves. A handful have special meaning and must be escaped with a backslash to match literally: . * + ? ^ $ ( ) [ ] { } | \. For example, to match a literal period, write \..

Character classes

• [abc] — any one of a, b, c.
• [^abc] — any character except those.
• [a-z0-9] — ranges.
• \d, \w, \s — digit, word character ([A-Za-z0-9_]), whitespace.
• \D, \W, \S — their negations.
• . — any character except newline (unless the s flag is on).

Anchors

• ^ — start of string (or line, with m).
• $ — end of string (or line, with m).
• \b — word boundary. Matches between a word character and a non-word character.

Quantifiers

• ? — 0 or 1.
• * — 0 or more.
• + — 1 or more.
• {n}, {n,}, {n,m} — exactly n, at least n, between n and m.

By default, quantifiers are greedy — they match as much as possible. Append ? to make them lazy, matching as little as possible. Compare <.*> against <b>bold</b> — greedy matches the whole string; <.*?> matches each tag individually.

Groups and alternation

• (abc) — capturing group. Available as $1 in replacements.
• (?:abc) — non-capturing group. Use when you only need grouping for | or quantifiers.
• (?<name>abc) — named capture.
• a|b — alternation (match either side).

Flags

• g — global. Find all matches, not just the first.
• i — case-insensitive.
• m — multiline. ^ and $ match at line boundaries.
• s — dotAll. . matches newlines.

Catastrophic backtracking — the bug that brings down services

The classic example is ^(a+)+$ against aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!. The engine tries every way to partition the as among the groups before failing. The Cloudflare 2019 outage and multiple ReDoS CVEs trace back to this pattern.

Two defenses:

• Avoid nested quantifiers that can match the same thing in multiple ways. Rewrite (a+)+ as a+.
• Set a timeout on any regex run against untrusted input, or use an engine with linear-time guarantees (RE2, Rust's regex crate).

Don't use regex for these

• Parsing HTML. HTML is not regular. Even a modest real-world page will defeat any regex. Use a proper parser (DOMParser in browsers, cheerio in Node).
• Parsing JSON, XML, or any nested structure. Same reason.
• Validating email addresses comprehensively. The full RFC 5321/5322 grammar is enormous. For signup forms, ^\S+@\S+\.\S+$ plus a confirmation email is better than a 500-character regex.
• Replacing logic you could express as a plain string operation. str.split(',') is clearer than a regex.

FAQ

UUIDs: what they are and which version to use

A UUID (Universally Unique Identifier) is a 128-bit value rendered as a 36-character string like 550e8400-e29b-41d4-a716-446655440000. The point is that you can generate one on any machine, at any time, without coordination, and be practically certain it won't collide with a UUID generated anywhere else.

Multiple versions exist — each solves a different problem:

• v4 (random) — 122 bits of randomness. What this tool generates. Good default for anything that doesn't need sortability.
• v7 (time-ordered) — timestamp in the high bits, random in the low bits. Finalized in RFC 9562 (2024). Better for database primary keys: lexicographic sort matches insert order, so B-tree indexes don't fragment.
• v1 — timestamp plus MAC address. Leaks which machine generated it and is largely superseded by v7.
• v3 / v5 — deterministic, hashed from a namespace and name. Useful when the same input should always produce the same UUID (e.g. derive a user's avatar ID from their email).

Unix timestamps without the confusion

A Unix timestamp is the number of seconds elapsed since 1970-01-01T00:00:00Z. That instant is called the Unix epoch. The value is the same everywhere on Earth at the same moment — it has no time zone.

Seconds vs. milliseconds

Most Unix tooling uses seconds (1718000000). JavaScript's Date.now() returns milliseconds (1718000000000) — three extra digits. This is the single most common timestamp bug: a value gets interpreted in the wrong unit and you end up in the year 56,000 or in 1970. A 10-digit number is seconds; a 13-digit number is milliseconds.

Year 2038 (Y2K38)

32-bit signed integers holding seconds overflow on 2038-01-19T03:14:07Z. If your stack still uses 32-bit time_t (some embedded systems, legacy filesystems), timestamps past that point wrap to negative numbers and get interpreted as 1901. Modern 64-bit systems are fine for the next several hundred billion years.

Time zones and timestamps

A Unix timestamp is zone-agnostic. A displayed date is not. Convert at the edges: store UTC, render in the user's local zone. The ISO 8601 representation with a Z suffix (e.g. 2026-04-18T15:30:00Z) is unambiguous and parseable in every language.

Case conversion — which case where?

• camelCase — JavaScript/TypeScript variables and functions; JSON keys in JavaScript-first APIs.
• PascalCase — class names, type names, React components, C# everything.
• snake_case — Python, Ruby, Rust variables and functions; SQL column names; JSON keys in Python-first or Rails APIs.
• kebab-case — URLs, CSS class names and custom properties, HTML attributes, filenames, npm package names.
• UPPER_SNAKE — environment variables, constants in most languages, SQL keywords by convention.
• Title Case — headings and UI labels (not code identifiers).

Consistency within a codebase matters more than the specific choice. Most style guides just say: match your language's convention, match any existing API contract, and don't mix on the same side of a boundary.

FAQ

What a diff actually shows

A diff is a compact description of how one text differs from another. Rather than showing both documents side by side, a diff picks out the lines that were added, removed, or changed — so you can focus on what's different instead of re-reading what's the same. It's the same view you get from git diff, from a pull request on GitHub, or from the "Compare" feature in most editors.

DevDecoder's diff is a line-based diff: it splits both inputs on newlines, finds the longest common subsequence of matching lines, and marks the rest as additions or deletions. That's the right granularity for config files, JSON payloads, log output, and source code.

When to use a diff

• Comparing API responses. Capture one response, change a parameter, capture the other — the diff tells you exactly which fields changed.
• Reviewing config changes. Before and after an environment migration, paste the two config files and see which values moved.
• Verifying redactions. Produce a version of a document with sensitive data removed, diff against the original, confirm nothing else changed.
• Spotting unintended changes. Paste a file you edited and its original to confirm your changes are scoped to what you intended.
• Comparing JWTs or decoded payloads. Format both tokens' payloads, diff them, see which claim differs.

Common pitfalls

• Line-ending drift. Files with \r\n (Windows) and files with \n (Unix) will diff as "every line changed" even when the content is identical. Strip \r before diffing, or use an editor that normalizes on paste.
• Trailing whitespace. A space at the end of a line makes two otherwise-identical lines look different. Turn on the "ignore whitespace" toggle above, or clean the inputs first.
• Minification. Minified JSON or minified JS is useless to diff directly — everything is one line. Pretty-print both sides first (the JSON formatter handles JSON; run JS through a formatter).
• Ordering in JSON. Most JSON libraries don't preserve key order. If you diff two JSON documents with the same data but different key order, every line will look changed. Canonicalize first (sort keys consistently) before diffing.
• Huge inputs. Classical line diff is O(m·n) in memory. Thousand-line inputs diff instantly; 100,000-line inputs will hang the tab. Split large files into chunks or use a local diff tool for those.

FAQ

What a QR code is

A QR (Quick Response) code is a two-dimensional barcode that encodes up to a few thousand characters of text in a square pattern of black and white modules. It was invented at Denso Wave in 1994 for tracking automotive parts and became the dominant way to move short payloads — URLs, Wi-Fi credentials, payment links, contact cards — between a physical medium and a phone camera.

The content is just text: a QR code does not care whether the text is a URL, a plain string, or a JSON blob. Whatever scanner reads it decides what to do with the result. A URL gets opened. A Wi-Fi string triggers a network join prompt. Anything else is shown as text.

Error correction: L, M, Q, or H?

QR codes include Reed–Solomon error correction so they still scan when part of the code is obscured, printed imperfectly, or faded. The cost is size: a higher correction level means more modules, so the same content produces a denser code.

If you plan to place a small logo in the middle of the code, bump to Q or H so the overlay doesn't break scanning.

Capacity, or why your URL might not fit

QR codes come in 40 different "versions," each with progressively more modules. At the highest version and lowest error correction, a code can hold around 4,296 alphanumeric characters or 2,953 bytes — plenty for any URL and most short payloads. But bigger versions produce denser codes that are harder to scan at small sizes.

Practical guidance:

• Keep URLs under ~100 characters where possible. Use a URL shortener if you're over that and scan quality matters.
• For Wi-Fi connect codes (WIFI:T:WPA;S:<ssid>;P:<password>;;), short SSIDs and passwords scan much more reliably than long ones.
• vCards fit, but minimize fields. A QR with name, phone, and email scans well; a QR with a full photo embedded does not.

Printing and display tips

• Quiet zone. Every QR code needs a white border of at least 4 modules around the pattern for scanners to find it. Don't crop it tight.
• Contrast. Black on white is safest. Colored codes work, but dark-on-light with high contrast is required. Avoid colored backgrounds that match the foreground.
• Inverted codes do not scan on most mobile scanners. Keep the modules darker than the background.
• Size for scanning distance. Rule of thumb: the code should be at least 1/10th of the distance the user will scan from. A code to be scanned at 30 cm should be at least 3 cm wide.
• Avoid glare on curved surfaces. If printing on a bottle or a non-flat medium, test from multiple angles before committing to a print run.

FAQ

Why another developer-tools site?

Most online decoders and formatters paste your input straight into a form, post it to a server, and show you the result. That's fine for a lorem ipsum generator — it's a real problem when the input is a production JWT, a customer's API response, or a hash of something sensitive. DevDecoder exists because a tool that touches tokens, keys, and payloads has no business sending them off-device.

Every operation you can run here — encoding, decoding, hashing, JWT decoding, JSON parsing, regex matching, UUID generation — executes in your browser. Open DevTools, open the Network tab, and use any tool: no request is made for the tool logic itself. Hashing uses the browser's SubtleCrypto API. UUIDs come from crypto.getRandomValues. There is no backend. (You will see background requests from Google AdSense, which is disclosed on the Privacy Policy.)

What's here

Encoding & decoding

Six formats covered: Base64 (with the same engine that powers data URIs and HTTP Basic auth), URL percent-encoding, HTML entity escaping, Hex, Binary, and ROT13. Each has its own tab on the Decode page, with explanations of when to use which.

Cryptographic hashes

A single input field produces MD5, SHA-1, SHA-256, SHA-384, and SHA-512 at once. Useful for checksums, HMAC setup, and matching a published file signature. Read the warnings on the Hash page before using any of these for password storage.

JWT decoding

Paste a JSON Web Token to see its decoded header and payload, plus an expiration badge showing whether the token is valid right now. Signature verification requires the key, which we never ask for — see the JWT page for how to verify server-side.

JSON, regex, and everyday utilities

A forgiving JSON formatter, a live regex tester with flag toggles and capture-group display, and a small utilities panel covering the three things you actually reach for between other tasks: a UUID, a timestamp conversion, and a case conversion.

Text diff

A line-based diff for comparing two text blocks — JSON payloads, config files, code snippets. Shows additions and deletions in a familiar +/- format with per-change line counts.

QR code generator

Turn any URL or short payload into a scannable QR code, with selectable size and error-correction level, and a one-click PNG download. Everything runs in-browser.

Reading guides

Longer-form pieces that go deeper than the inline explanations on each tool page:

• Base64 vs. URL encoding: which to use and when Both make text safe to transport, but they solve different problems and are not interchangeable.
• How to debug a JWT that won't validate A checklist for the nine things that commonly break signature verification, from clock skew to the alg: none bug.
• MD5, SHA-1, SHA-256, SHA-512: what to use in 2026 A plain-English look at which algorithms are still safe, which are broken, and why password hashing is a different question.
• Regex lookahead and lookbehind, explained Zero-width assertions are the regex feature that unlocks validation patterns you can't write any other way.

The privacy story, briefly

No backend. No analytics requests on tool usage. No input data leaves the browser. The only data we touch is a single theme value in localStorage so your dark-mode choice persists. Google AdSense is loaded for ads, which brings its own cookies — those are disclosed on the Privacy Policy.

Questions, bug reports, or feature requests are welcome — see the Contact page.