. In CSS: background-image: url('data:image/svg+xml;base64,PHN2Zy...'). This is ideal for small icons and SVGs (under ~5 KB). For larger files, separate file references are more efficient because Base64 adds 33% size overhead and bypasses browser caching.
**Q: What is the maximum input size?**
A: This browser-based tool efficiently handles text up to about 5 MB. For very large files or binary data, consider using command-line tools like 'base64' (available on macOS and Linux) or 'openssl base64'. The Base64 standard itself has no size limit.
**Q: What characters are in the Base64 alphabet?**
A: The standard Base64 alphabet (RFC 4648) consists of 64 characters: uppercase letters A-Z (values 0-25), lowercase letters a-z (values 26-51), digits 0-9 (values 52-61), plus sign + (value 62), and forward slash / (value 63). The equals sign = is used for padding. The URL-safe variant (Base64URL) replaces + with - and / with _ to avoid conflicts with URL-reserved characters.
**Q: I need to embed a small image in my HTML email template — should I use Base64 data URIs or host the image externally?**
A: For HTML email, Base64 data URIs are actually the recommended approach for small images like logos and icons. Many email clients (Outlook, Gmail) aggressively block externally hosted images by default, requiring users to click "Display images" to see them. Embedding images as Base64 data URIs (data:image/png;base64,...) bypasses this problem entirely — the image is part of the email itself. The tradeoff is email file size: Base64 adds ~33% overhead, so a 10 KB PNG becomes ~13 KB in the email. Keep embedded images under 20 KB for best compatibility. For larger images or backgrounds, hosting externally is more practical. Use this tool to encode your image file's bytes to Base64 for embedding.
**Q: Why does my Base64 encoded string have + and / characters that break my URL parameters?**
A: Standard Base64 uses + and / as two of its 64 characters, and both have special meaning in URLs (+ means space, / is a path separator). When you include a standard Base64 string in a URL query parameter without encoding, these characters corrupt the value. The solution is to use URL-safe Base64 (also called Base64URL, defined in RFC 4648), which replaces + with - and / with _. This variant is used in JWT tokens, OAuth flows, and any Base64 value that appears in URLs. To convert standard Base64 to URL-safe, simply replace all + with - and / with _ in the output, and optionally remove the = padding characters.
**Q: I'm trying to decode a JWT token — how does Base64URL decoding work and how is it different from standard Base64?**
A: A JWT (JSON Web Token) consists of three parts separated by dots: header.payload.signature. The header and payload are each encoded with Base64URL — not standard Base64. Base64URL differs from standard Base64 in two ways: it uses - instead of + and _ instead of /, and it omits the = padding characters. To decode a JWT manually, split the token by dots, take the first or second segment, replace - with + and _ with /, add = padding if needed to make the length a multiple of 4, then Base64-decode. Most JWT debugging is easier with a dedicated JWT decoder, but understanding the Base64URL encoding helps when implementing token handling in code or debugging raw token values.
---
### Base64 to Image Converter
URL: https://go-tools.org/tools/base64-to-image
Decode a Base64 string or data URI back into an image in your browser. Preview, read dimensions & MIME, then download as PNG, JPG, GIF, SVG. No upload.
#### What is Base64 to Image Decoding?
Base64 to image decoding is the reverse of encoding: it takes a string of printable ASCII characters from the Base64 alphabet (A–Z, a–z, 0–9, + and /) and reconstructs the original binary image the string represents. Every group of four Base64 characters maps back to three bytes, and one or two trailing = characters indicate padding. The result is the exact file that was originally encoded — a PNG comes back as a PNG, a JPEG as a JPEG — with no loss, recompression, or resizing.
These strings show up wherever an image has been inlined as text. A data URI in a stylesheet (background-image: url(data:image/png;base64,…)), an img src in HTML, a thumbnail field in a JSON API response, an embedded logo in HTML email, or an asset bundled into a config file are all Base64 images waiting to be decoded. When you are debugging, auditing, or extracting such an asset, you need to see what the opaque string actually is and pull it out as a real file — which is exactly what this decoder does.
The operation is purely mechanical and requires no key, because Base64 is an encoding rather than encryption. That also means it offers no security: anyone with the string can recover the image instantly. Base64 exists solely to let binary data pass through channels designed for text — HTML, JSON, URLs, email headers — without being corrupted by control characters or delimiters. Decoding simply undoes that text-safe packaging and hands you back the original bytes.
This tool performs the entire decode locally in your browser. It tolerates the messiness of real-world strings — missing data: prefixes, line wrapping at 76 characters, stray whitespace from copy-paste — and infers the image format from the data's magic bytes when the MIME type is not declared. To create these strings in the first place, see the companion $2b$12$dUSFKqT1FCMYZ6hcQfsxuONizEqcX8IGK8snfVSowP5Uu.TDJoPUq. It packs four parts: the version ($2b$), the cost (12, a logarithmic work factor), a 22-character Base64 salt, and the 31-character Base64 digest. Because the salt is random and embedded in the hash, the same password produces a different hash every time — which defeats rainbow tables and hides the fact that two users picked the same password. Verification reads the salt and cost back out of the stored hash and re-hashes the candidate, so bcrypt never needs to (and cannot) reverse a hash to recover the password.
This tool runs entirely in your browser using a bundled bcrypt implementation — no password or hash is ever uploaded. Use it to generate a hash with a chosen cost and prefix, to verify a password against an existing hash, and to read a hash's anatomy. It pairs naturally with other security tools: protect a directory with HTTP Basic Auth using our htpasswd Generator (which can emit bcrypt entries directly), mint a strong password to hash with our Random Password Generator, and reach for our SHA-256 Generator when you need a fast general-purpose checksum rather than a slow password hash. If you are deciding which algorithm to store passwords with, compare the options in bcrypt vs Argon2 vs scrypt.
```
// Node.js — bcryptjs / bcrypt (emits $2b$)
const bcrypt = require('bcrypt');
const hash = await bcrypt.hash('correct horse battery staple', 12);
// -> $2b$12$dUSFKqT1FCMYZ6hcQfsxuONizEqcX8IGK8snfVSowP5Uu.TDJoPUq
const ok = await bcrypt.compare('correct horse battery staple', hash); // true
# Python — bcrypt
import bcrypt
hashed = bcrypt.hashpw(b'correct horse battery staple', bcrypt.gensalt(12))
bcrypt.checkpw(b'correct horse battery staple', hashed) # True
# PHP — password_hash (emits $2y$)
$hash = password_hash('correct horse battery staple', PASSWORD_BCRYPT, ['cost' => 12]);
password_verify('correct horse battery staple', $hash); // true
# Apache htpasswd CLI — bcrypt entry to stdout (-B bcrypt, -b inline, -n stdout)
htpasswd -Bbn admin 'correct horse battery staple'
# -> admin:$2y$12$dUSFKqT1FCMYZ6hcQfsxuONizEqcX8IGK8snfVSowP5Uu.TDJoPUq
```
#### FAQ
**Q: Is an online bcrypt generator safe to use?**
A: With this one, yes — because nothing you type ever leaves your browser. The password, the generated hash, and the verification all run locally in JavaScript on your own device. There are no network requests, no logging, and no storage: you can confirm it by opening your browser's Developer Tools (F12 → Network tab) while you generate a hash and watching for zero outgoing requests, or by disconnecting from the internet and seeing the tool keep working. That is the opposite of a sketchy generator that POSTs your password to a server. As a habit, still prefer a throwaway test password over a real production one whenever you are just experimenting.
**Q: How do I generate a bcrypt hash online?**
A: Open the Generate tab, type a password (or click Random password to mint a strong one), pick a cost factor — 12 is the modern default — and choose a version prefix: $2b$ for most modern stacks, $2y$ for PHP and Apache, or $2a$ for the original identifier. The bcrypt hash is computed instantly in your browser with a fresh random salt and appears as a single 60-character $2b$12$... string you can copy with one click. Nothing is uploaded: the password and hash never leave your device. Generate again any time to get another valid hash for the same password, since each one carries a different random salt.
**Q: Can a bcrypt hash be decrypted or reversed?**
A: No. bcrypt is a one-way password hashing function, not encryption, so there is no key and no decrypt operation that turns a hash back into the original password. The only way to learn the password from a hash is to guess candidates and hash each one until it matches — which is exactly what bcrypt's adjustable cost factor is designed to make slow and expensive. That is why you verify a password against a hash rather than decrypt it: the tool re-hashes your candidate with the salt and cost stored in the hash and checks whether the result is identical.
**Q: What cost factor (work factor) should I use?**
A: Cost 12 is the modern default and a sensible balance of security and speed. The cost is a logarithmic work factor: each increment doubles the number of internal rounds, so cost 13 takes roughly twice as long to compute and verify as cost 12, and cost 11 takes half as long. Higher costs slow down attackers brute-forcing leaked hashes, but they also add latency to every legitimate login, so do not raise it past the point where authentication feels sluggish on your real hardware. Cost 10 is acceptable for low-risk endpoints; 12–14 suits anything sensitive. The valid range is 4 to 31, and this tool lets you pick 4 to 15.
**Q: What's the difference between $2a$, $2b$, and $2y$?**
A: They are version prefixes for the same bcrypt algorithm, and the differences trace back to historical bug fixes in how some implementations handled string length and high-bit characters. $2a$ is the original widely used identifier; $2b$ is the corrected current version that the bcryptjs library and most modern implementations emit; and $2y$ is the identifier PHP and Apache's htpasswd use. For verification they are interchangeable — a hash you generate here with any prefix will validate correctly across libraries, because they all run the same core function. Pick the prefix your stack expects if you need byte-for-byte compatibility.
**Q: How do I verify a password against a bcrypt hash?**
A: Switch to the Verify tab, paste the stored bcrypt hash (the full $2b$12$... string) and the candidate password, and the tool tells you instantly whether they match. It works by extracting the salt and cost embedded in the hash, re-hashing the candidate password with those exact parameters, and comparing the new digest to the stored one — there is no decryption involved. This is how a login system checks a password: it never recovers the plaintext, it only confirms that re-hashing the submitted password reproduces the stored hash.
**Q: bcrypt vs Argon2 vs scrypt — which should I use?**
A: All three are deliberately slow, salted password-hashing functions, and all are far better than a bare SHA-256 for storing passwords. bcrypt is the most widely supported and battle-tested, with a simple tunable cost; its main limits are a 72-byte password cap and that it is CPU-bound only. scrypt adds memory hardness, making large-scale GPU/ASIC attacks costlier. Argon2 (specifically Argon2id) is the current recommendation from the Password Hashing Competition and OWASP, tuning time, memory, and parallelism independently. If you are choosing fresh today, Argon2id is the strongest default; bcrypt remains an excellent, safe choice — especially where library support or interoperability matters. We cover the tradeoffs in depth in bcrypt vs Argon2 vs scrypt.
**Q: Why is the bcrypt hash different every time?**
A: Because bcrypt generates a fresh random salt for every hash, and the salt is mixed in before hashing. The same password therefore produces a completely different 60-character string each time you click Generate — and that is the point: it stops attackers from precomputing rainbow tables or spotting that two users share a password. The salt is not secret; it is stored right inside the hash (the 22 characters after the cost), so verification can read it back out. If you re-roll the hash you simply get another valid hash for the same password, and every one of them will verify successfully.
---
### Case Converter — UPPERCASE, lowercase, camelCase & More
URL: https://go-tools.org/tools/case-converter
Convert text between UPPERCASE, lowercase, Title Case, Sentence case, camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE and 6 more formats instantly. Free, browser-only, no signup.
#### What Is a Case Converter?
A case converter is a small utility that takes a piece of text and re-renders it in a different letter-case convention. The simplest forms are UPPERCASE and lowercase — flip every letter to one case. The richer forms apply linguistic rules (Title Case capitalizes the first letter of every word, Sentence case capitalizes the first letter of each sentence) or programming-naming rules (camelCase joins words by capitalizing each one after the first; snake_case lowercases everything and joins with underscores). Online case converters have existed for as long as the web has had textareas, because the conversion is mechanically simple but tedious to do by hand for any non-trivial amount of text.
The text-case family is the one writers, editors, marketers, and journalists reach for. UPPERCASE and lowercase are useful for matching house style or removing shouty ALL-CAPS from a forwarded email. Title Case is for headings and book titles. Sentence case is the modern web standard for body text, UI microcopy, button labels, and captions — Google, Apple, and Microsoft's style guides all converged on it over the last decade. The mocking variants (iNVERSE cASE, aLtErNaTiNg cAsE, RaNdOm CaSe) come from internet culture, particularly the "spongebob meme" used to sarcastically quote someone; alternating case is the strict deterministic variant, random case is the chaotic one.
The programming-case family is the one developers use every single day. camelCase is the standard for JavaScript, Java, Swift, and Kotlin identifiers. PascalCase is the standard for class names in most object-oriented languages and component names in React, Vue, and Angular. snake_case is the standard for Python, Ruby, Rust, and Elixir, plus most database column names. kebab-case is the standard for CSS class names, URL slugs, and HTML attributes. CONSTANT_CASE is the standard for environment variables, top-level constants, and macro names. dot.case is used for namespacing (Java packages, MongoDB field paths). path/case is used for URLs and filesystem paths. Header-Case is the canonical HTTP/1.1 header convention (Content-Type, Access-Control-Allow-Origin).
Under the hood, the interesting engineering is the tokenizer that splits an input string into its semantic words. It's easy to split on whitespace; the hard part is recognizing word boundaries that don't have a whitespace separator. The standard convention — used by lodash, the change-case npm package, Python's PEP 8, and most real-world codebases — inserts a boundary at three transitions: lower-to-upper (parseHTML → parse / HTML), upper-to-upper-to-lower (XMLHttpRequest → XML / Http / Request), and letter-to-digit / digit-to-letter (file2x → file / 2 / x). Plus the explicit separators: hyphen, underscore, dot, slash, backslash. With that single tokenizer, you can paste an identifier in any case — camelCase, snake_case, kebab-case, mixed — and convert to any other case cleanly without manual cleanup.
The tool you're using runs the tokenizer and all 15 transforms entirely in your browser using JavaScript. There's no network call, no server, no logging, no cookie that records what you type. The output for every case updates on every keystroke with no debounce delay. The Copy button on each card writes only that one case to your clipboard. Re-shuffle re-rolls the random case without disturbing the other outputs. Everything is designed for the speed of actual work — paste, scan, copy, paste somewhere else.
For related text tooling, the word counter handles length and reading-time metrics, the text diff compares two pieces of text line by line, and the regex tester verifies pattern matches against sample input. Together they cover most of the text-shaping work a developer or content worker does in a browser.
```
// The tokenizer that powers every programming-case conversion
function tokenize(input) {
return input
.replace(/([a-z0-9])([A-Z])/g, '$1 $2') // lower→upper: parseHTML → parse HTML
.replace(/([A-Z]+)([A-Z][a-z])/g, '$1 $2') // acronym boundary: XMLHttp → XML Http
.replace(/([A-Za-z])(\d)/g, '$1 $2') // letter→digit: file2 → file 2
.replace(/(\d)([A-Za-z])/g, '$1 $2') // digit→letter: 2x → 2 x
.replace(/[\s\-_./\\]+/g, ' ') // collapse separators
.split(' ').filter(Boolean);
}
// Then each case is a one-liner over the tokens
const camelCase = (s) => tokenize(s).map((t, i) => i === 0 ? t.toLowerCase() : cap(t)).join('');
const snakeCase = (s) => tokenize(s).map(t => t.toLowerCase()).join('_');
const kebabCase = (s) => tokenize(s).map(t => t.toLowerCase()).join('-');
const PascalCase = (s) => tokenize(s).map(cap).join('');
function cap(t) {
return t.charAt(0).toUpperCase() + t.slice(1).toLowerCase();
}
```
#### FAQ
**Q: What does a case converter do?**
A: A case converter takes a piece of text and re-renders it in a different case — UPPERCASE, lowercase, Title Case, Sentence case, or one of the programming-naming cases like camelCase, PascalCase, snake_case, kebab-case, and CONSTANT_CASE. This tool shows all 15 common variants at once so you don't have to pick which conversion you want before pasting; you paste, scan the grid, and copy the one you need. It runs entirely in your browser using JavaScript — no signup, no upload, no server roundtrip, and no analytics on the text you paste.
**Q: What's the difference between camelCase, PascalCase, and snake_case?**
A: All three are conventions for naming multi-word identifiers in code. camelCase starts with a lowercase letter and capitalizes each subsequent word with no separator: `userProfileImage`. PascalCase capitalizes every word including the first: `UserProfileImage` — used for class names in most languages and component names in React. snake_case lowercases everything and joins words with underscores: `user_profile_image` — the convention for Python, Ruby, Rust, and most database column names. kebab-case is the same idea with hyphens: `user-profile-image` — used for CSS class names, URL slugs, and HTML attributes. CONSTANT_CASE is uppercase with underscores: `USER_PROFILE_IMAGE` — for constants and environment variables. Pick the one that matches your codebase's existing style.
**Q: How does the tokenizer handle acronyms like XMLHttpRequest or parseHTML?**
A: The tokenizer recognizes the upper-to-upper-to-lower boundary (XMLHttp → XML / Http) and the lower-to-upper boundary (parseHTML → parse / HTML). So `XMLHttpRequest` becomes the tokens `XML`, `Http`, `Request`, and converts cleanly to `xml_http_request`, `xml-http-request`, `XML_HTTP_REQUEST`, or `Xml-Http-Request`. This matches the convention used by lodash, the change-case npm package, and Python's PEP 8 — the de facto standard for acronym handling across languages. The one tradeoff: when converting back to PascalCase, the acronym becomes title-cased (`XMLHttpRequest` round-trips to `XmlHttpRequest`), which is also the standard convention to avoid ambiguity in re-tokenization.
**Q: What is Title Case versus Sentence case?**
A: Title Case capitalizes the first letter of every word, leaving everything else lowercase: `Hello World Example`. This tool uses the naive variant — every word capitalized — which is what most people mean by "title case" in casual usage. Some style guides (APA, Chicago, AP) recommend lowercasing short articles and prepositions like `a`, `an`, `the`, `of`, `in`, `for`; those variants are different enough that they belong in a separate "headline" tool. Sentence case capitalizes only the first letter of each sentence (and the very first letter of the input): `Hello world example. This is a sentence.` Use Title Case for headings and book titles, Sentence case for descriptions, captions, and body text.
**Q: Is my text uploaded anywhere?**
A: No. Every case transform runs 100% in your browser using JavaScript. Your text is never transmitted, never stored on any server, never logged, and never analyzed by humans or AI. You can verify in your browser's Network tab — typing in the editor or clicking Copy triggers zero network requests. This makes the tool safe for unannounced product names, internal variable schemes, draft legal text, journalist source notes, and any other confidential material. The tool also uses no cookies for the input text.
**Q: How do I convert text to camelCase from any other case?**
A: Paste your text into the editor above and copy the camelCase output card. It works from any starting format: a sentence with spaces (`hello world` → `helloWorld`), snake_case (`hello_world` → `helloWorld`), kebab-case (`hello-world` → `helloWorld`), PascalCase (`HelloWorld` → `helloWorld`), CONSTANT_CASE (`HELLO_WORLD` → `helloWorld`), or even a mixed acronym (`XMLHttpRequest` → `xmlHttpRequest`). The smart tokenizer recognizes all the common boundaries automatically, so you don't have to pre-clean the input.
**Q: Does the tool support Unicode and non-English letters?**
A: Yes. The case transforms use the JavaScript Intl-aware `toLocaleLowerCase()` and `toLocaleUpperCase()` methods, which correctly handle Turkish dotted/dotless `İ`/`ı`, German `ß` (which uppercases to `SS` in standard handling), Greek final-sigma, and other locale-sensitive case mappings. Tokenization uses Unicode-aware regex patterns that recognize letters from any script (`\p{L}`). For programming-case outputs (camelCase, snake_case, etc.), the tokenizer treats only ASCII letters and digits as identifier characters by default — which matches the constraints of most programming languages — so non-Latin letters in the input pass through unchanged inside tokens.
**Q: What's the difference between dot.case and path/case?**
A: Both are lowercase, separator-joined identifiers — the only difference is the separator. `dot.case` uses periods: `hello.world.example`. It's common for namespacing (Java packages, Lodash methods, MongoDB field paths) and config-file keys (TOML, INI). `path/case` uses forward slashes: `hello/world/example`. It's the convention for URL paths, filesystem paths, and Git refs. Both are produced from the same tokenization, so converting between them is just a separator swap. Use dot.case when the identifier represents a hierarchical key inside data; use path/case when it represents a literal location.
**Q: Why does the tokenizer split on numbers (file2x → file, 2, x)?**
A: Numbers as token boundaries are the convention most modern codebases follow — `parseUTF8` should round-trip to `parse_utf_8` (or `parseUtf8` in PascalCase), not `parseutf_8`. The tokenizer treats every letter-to-digit and digit-to-letter transition as a boundary, so `file2x` becomes `file / 2 / x`. If you'd prefer to keep digits glued to the preceding letters, paste a manually-tokenized version (`file 2x` with a literal space) and the tokenizer will respect the space. This convention matches the change-case package and PEP 8 for Python.
**Q: How is alternating case different from random case?**
A: Alternating case (aLtErNaTiNg cAsE) flips between lowercase and uppercase deterministically — every odd letter is uppercase, every even letter is lowercase, regardless of word boundary. The result is the same every time for the same input. Random case (RaNdOm CaSe) flips each letter independently with a coin-flip, so every paste produces a different result. Click Re-shuffle to re-roll the random output without clearing the editor. Both are mocking-text formats (the so-called "spongebob meme"); alternating is the strict variant, random is the chaotic one. Other case outputs aren't affected by Re-shuffle.
**Q: Does this convert HTTP header names?**
A: Yes — use the Header-Case output. It capitalizes every token and joins with hyphens, producing canonical HTTP header spellings like `Content-Type`, `Access-Control-Allow-Origin`, and `X-Forwarded-For`. Paste a camelCase JS property name (`accessControlAllowOrigin`) and you get the exact header spelling the HTTP/1.1 spec uses, ready to drop into a `fetch()` options object or a server-side response. Note that HTTP/2 prefers lowercase header names (use kebab-case for that variant); HTTP/1.1 is case-insensitive but the Header-Case spelling is the conventional human-readable form.
**Q: Can I convert a whole paragraph at once?**
A: Yes — for the text-case transforms (UPPERCASE, lowercase, Title Case, Sentence case, iNVERSE, aLtErNaTiNg, RaNdOm), the tool preserves all whitespace, line breaks, and punctuation by design, so you can paste an entire paragraph or even a multi-page document. The programming-case transforms (camelCase, snake_case, etc.) deliberately strip punctuation since they produce identifiers; pasting a paragraph into camelCase will collapse it into one giant identifier, which is technically the correct transform but rarely useful. For document-length text, use the text-case outputs only; for identifier conversion, paste one identifier at a time.
**Q: How accurate is this versus lodash, change-case, or other case libraries?**
A: The tokenizer and case transforms produce byte-identical output to the change-case npm package (`change-case` v5+) for all common inputs — same handling of acronyms, same number-as-boundary rule, same Unicode letter recognition. lodash's `_.camelCase`, `_.snakeCase`, `_.kebabCase`, and `_.startCase` use a slightly different tokenizer (it splits on more characters and treats some Unicode classes differently), but for ASCII inputs the outputs match for the common cases. The Title Case in this tool is the naive variant (every word capitalized); lodash's `_.startCase` does the same. If you need APA or Chicago title-case rules (lowercase short prepositions), use a dedicated title-case library — this tool optimizes for the case most people search for.
**Q: Why are there both Sentence case and Title Case if they look similar?**
A: They diverge as soon as the input has more than one word. Sentence case lowercases everything and capitalizes only the first letter of each sentence: `hello world. this is a sentence.` becomes `Hello world. This is a sentence.` Title Case capitalizes every word: `Hello World. This Is A Sentence.` Sentence case is the convention for body text, captions, and UI microcopy in most modern style guides (Google, Microsoft, Apple). Title Case is the convention for headings, page titles, book titles, and dialog window titles in classical typography. Modern web style increasingly prefers Sentence case for everything except primary headlines.
---
### chmod Calculator — Linux File Permissions
URL: https://go-tools.org/tools/chmod-calculator
Convert Linux file permissions between octal (755, 644) and rwx symbols. Get chmod commands, spot risky settings like 777 — free, right in your browser.
#### What Is chmod?
chmod — change mode — is the Unix and Linux command that sets who may read, write or execute a file. Every file carries nine permission bits in three groups (owner, group, others), and chmod accepts them either as an octal number in numeric (absolute) mode, like chmod 755, or as letters in symbolic mode, like chmod u=rwx,go=rx. Both describe exactly the same bits; this calculator translates between them live.
The octal shorthand works because each permission is a power of two: read is 4, write is 2, execute is 1, and one digit per class is simply their sum. So 7 is everything (4+2+1), 5 is read plus execute, 6 is read plus write, and 0 is nothing at all. Read rwxr-xr-x left to right in threes and you get 7, 5, 5. A fourth, leading digit encodes the special modes — setuid (4), setgid (2) and the sticky bit (1) — which is how 4755 or 1777 arise; their presence shows up in the symbolic string as s or t in place of x.
Permissions are the first layer of Unix security, and most day-to-day permission problems reduce to a handful of patterns: a script that will not run needs execute (u+x), a directory you cannot enter is missing its x bit, a web asset should be 644 with 755 directories above it, and a private key must be 600 before OpenSSH will touch it. The mistakes cluster the same way — most infamously chmod 777, which "fixes" access errors by handing write access to every account on the machine. This page keeps the arithmetic, the symbols, the ready-to-run commands and the risk warnings in one place, and since octal is just base 8, you can explore the underlying positional arithmetic with the number base converter.
```
# Make a script executable, then verify with ls -l
$ ls -l deploy.sh
-rw-r--r-- 1 jack staff 512 Jul 17 10:00 deploy.sh
$ chmod 755 deploy.sh
$ ls -l deploy.sh
-rwxr-xr-x 1 jack staff 512 Jul 17 10:00 deploy.sh
# The symbolic equivalent of 755
$ chmod u=rwx,go=rx deploy.sh
# Read the current mode as a number
$ stat -c '%a' deploy.sh # Linux → 755
$ stat -f '%Lp' deploy.sh # macOS → 755
```
#### FAQ
**Q: What does chmod 777 mean?**
A: It grants read, write and execute to everyone — owner, group and all other users alike. Each digit is a sum of read (four), write (two) and execute (one) for one class of user, and the maximum value in every position means nobody is restricted in any way. In symbolic form it is rwxrwxrwx. There are legitimate uses, but they are rare and almost always directories rather than files; when a tutorial tells you to chmod 777 something to "make it work", the actual problem is nearly always ownership, and chown is the correct fix.
**Q: Is chmod 777 dangerous?**
A: On anything reachable by other users or by a web server, yes: 777 means any account on the system — including a compromised service account — can replace the file's contents or drop new files into the directory. Web-server document roots set to 777 are a classic path to defaced sites and injected malware. The exception that proves the rule is 1777: adding the sticky bit, as /tmp does, lets everyone create files while preventing users from deleting each other's — this calculator flags plain 777 as a risk but recognises 1777 as the standard shared-directory pattern.
**Q: What is the difference between chmod 755 and 644?**
A: The execute bit. 755 (rwxr-xr-x) lets everyone execute or traverse, which is what directories, scripts and binaries need; 644 (rw-r--r--) is the same thing without any execute permission, which is right for regular files like HTML pages, images and config files. The classic pairing is 755 for every directory and 644 for every file inside — the files-only and directories-only commands this calculator generates produce exactly that split with find -type d and find -type f.
**Q: How do I fix "Permissions 0644 for 'id_rsa' are too open"?**
A: Run chmod 600 ~/.ssh/id_rsa and connect again. OpenSSH refuses to use a private key that any other account could read: it prints the banner WARNING: UNPROTECTED PRIVATE KEY FILE!, the line Permissions 0644 for '/home/user/.ssh/id_rsa' are too open., states that private key files must NOT be accessible by others, and then ignores the key — which surfaces as a sudden password prompt or Load key ... bad permissions. Mode 600 (rw-------) satisfies the check; 400 (r--------) also works and additionally guards against accidental overwrites. See the OpenSSH manual for the key-file requirements.
**Q: What is the difference between chmod and chown?**
A: chmod changes what the existing owner, group and others may do with a file — its permission bits. chown changes who the owner and group actually are. They solve different problems: if a web server cannot write its own upload directory, the fix is usually chown www-data:www-data on the directory, not loosening permissions for the whole world with chmod. A good habit when something is unexpectedly unreadable: check ownership first with ls -l, decode the mode (paste the line into this calculator), and only then decide which of the two commands the situation calls for.
**Q: What does chmod +x do?**
A: It adds the execute bit for the user classes not masked by your umask — with the common umask of 022 that means everyone, so chmod +x script.sh is usually equivalent to chmod a+x script.sh and turns a file the shell refuses to run into an executable one. Under a stricter umask like 077, however, +x only affects the owner. If you want a specific outcome regardless of umask, say it explicitly: u+x for just the owner, a+x for everyone. Directories need the same bit to be entered at all, which is why they are 755 rather than 644 by default.
**Q: How do I chmod all files and folders recursively?**
A: Avoid a blanket chmod -R 755: it makes every regular file executable, which is noise at best and a risk at worst. The clean way is to treat directories and files separately — find dir -type d -exec chmod 755 {} + for directories and find dir -type f -exec chmod 644 {} + for files, both of which this calculator generates for your chosen mode. GNU chmod's capital X does the same in one line (chmod -R u+rwX,go+rX dir): it adds execute only to directories and to files that are already executable. One Linux subtlety: a plain numeric chmod like 755 leaves an existing setuid/setgid bit on directories in place — clear it explicitly with 00755 or u-s,g-s if that is what you intend.
**Q: Is my data uploaded when I use this calculator?**
A: No. Every conversion happens locally in your browser with plain JavaScript bit arithmetic — there is no server call, no analytics event tied to what you type, and nothing to retain. You can open your browser's developer tools and watch the network panel stay silent while you toggle permissions, or go offline entirely and keep working. The Copy link button encodes the current mode in the URL fragment, and fragments are never sent to a server either.
---
### Color Converter — HEX, RGB, HSL & OKLCH
URL: https://go-tools.org/tools/color-converter
Convert HEX to RGB, HSL, OKLCH, OKLAB and CMYK in your browser — copy any format with one click. Free, no signup, your colors never leave the page.
#### What Is a Color Converter?
A color converter is a small utility that translates a single color value between the formats your toolchain, your design system, and your browser actually understand — HEX, RGB, HSL, HSV, HWB, CMYK, OKLCH, OKLAB, and the 148 CSS named colors. Online converters have been a staple of web tooling since the early 2000s, back when the answer was almost always a simple HEX-to-RGB textbox built for a Geocities-era stylesheet. What separates a modern converter from those legacy tools is three things: a unified-field UX where every format is simultaneously editable instead of a one-direction dropdown, an OKLCH source-of-truth that holds the canonical value internally so round-trips stay bit-stable, and perceptual math grounded in W3C CSS Color 4 instead of the gamma-tangled HSL arithmetic the 2003 generation shipped.
Different color spaces exist because different problems need different representations, and no single space is good at all of them. RGB is hardware-native — it maps directly to the red, green, and blue subpixels of an LCD or the phosphors of a CRT, with each channel encoded as an 8-bit integer from 0 to 255. HEX is just RGB in base-16, packed into a six-character string for terse CSS and Figma copy-paste. HSL, HSV, and HWB are designer-cognitive spaces — cylindrical reshapes of RGB that let you rotate hue, lighten, or darken with intuitive sliders. HSL was published in 1978 alongside HSV by Alvy Ray Smith; HWB was added in 1996 as a cleaner mental model (Hue + amount of White + amount of Black). CMYK is a print-process abstraction — a subtractive ink stack (Cyan, Magenta, Yellow, Key=black) that models how ink absorbs light on paper rather than how a screen emits it. OKLCH and OKLAB are perceptual spaces — they're designed so that equal numeric distance corresponds to equal perceived distance, which makes them indispensable for design-system ramps and accessibility math. Named colors are CSS legacy: the 148 SVG/CSS3 names like `tomato`, `rebeccapurple`, and `slategray` that ship with every browser.
For more than twenty years sRGB was "good enough" — a 1996 IEC standard built around the phosphor primaries of the CRT monitors of the day. It quietly defined the upper bound of what a web color could mean. Then wide-gamut displays broke the assumption. Apple's Display P3 covers roughly 50% more of the visible spectrum than sRGB and now ships in every iPhone, iPad, and MacBook from 2017 onward. Rec.2020 covers even more and is the broadcast standard for HDR TV. HSL embedded sRGB's gamma quirks deep in its definition, which is why an HSL ramp looks visually uneven on a wide-gamut display — a green at L=50% looks brighter than a blue at L=50%, because HSL's L is geometric, not perceptual. In 2020 Björn Ottosson published OKLAB, a perceptually-uniform color space derived from CIE-LAB with corrected lightness response and cleaner behavior at high saturation. OKLCH is its polar form (Lightness / Chroma / Hue), the same shape as HSL but with the perceptual math fixed. CSS Color 4 added `oklch()` and `oklab()` syntax in 2022; Chrome 111 shipped support in March 2023, Safari 15.4 already had it as of March 2022, and Firefox 113 landed in May 2023. Tailwind v4, released in 2025, made OKLCH its default color token format; shadcn/ui followed shortly after. This tool reflects that shift by making OKLCH the internal source of truth — every conversion routes through OKLCH, so a HEX → RGB → OKLAB → HEX round-trip never accumulates float drift, and editing the L channel of OKLCH directly updates every other field exactly.
Which space you reach for depends entirely on what you're doing. **HEX** is the right call for web embedding, copy-paste between design tools and code, and anywhere terse identifiers matter — `#3b82f6` fits in a CSS variable comfortably and most front-end developers can read it on sight. The dedicated hex to RGB converter handles the single most common direction one-step; the reverse RGB to hex converter covers the case where you have separate channel integers from a designer or image-pixel-math pipeline. **RGB** is for direct hardware addressing — anywhere you need 0-255 integers (canvas APIs, image manipulation, hardware LED strips, OpenGL color attributes). **HSL** is the legacy designer-cognitive space — rotate hue, lighten, darken — and still useful when you need a quick CSS color tweak in a project that hasn't migrated to OKLCH. The single-direction hex to HSL converter is the right shortcut when that's all you need. **HSV and HWB** are designer color-picker spaces. HSV (Hue, Saturation, Value) matches the saturation-value square most picker UIs draw, so it's what Photoshop, Figma, and Sketch report when you click the eyedropper. HWB is the cleaner mental model — pick a pure hue, then add white to lighten or black to darken — and CSS Color 4 added native `hwb()` support across all evergreen browsers. **CMYK** is for print preparation. A blunt disclaimer: our CMYK output is a naive sRGB-based approximation using the standard `K = 1 - max(R,G,B); C = (1-R-K)/(1-K)` formula. Real print accuracy requires ICC profile conversion against the specific press, ink, and paper — typically US Web Coated SWOP v2 or Fogra39 — which can shift channels by 5-15%. Treat our CMYK as a starting estimate, not a deliverable. The single-direction hex to CMYK converter applies the same formula with the same caveat. **OKLCH** is the default choice for new code in 2025 and forward — modern design systems, accessibility-aware palette generation, anywhere perceptual uniformity matters. The single-direction hex to OKLCH converter exists for quick legacy-palette migration. **OKLAB** is the rectangular cousin used for palette math: mid-points between two colors, distance calculations, color-blindness simulation matrices, and other operations that need linear-axis arithmetic. **Named colors** are for documentation, code comments, mocks, and prose — the 148 CSS named colors are a fixed dictionary, and the tool finds the closest named color for any input via ΔE distance in OKLAB.
The conversion graph at the heart of all this is well-defined and surprisingly clean. sRGB and linear-sRGB are related by a piecewise gamma curve specified in W3C CSS Color 4 §11.2 (roughly a 2.4 exponent with a small linear segment near zero). Linear-sRGB and CIE XYZ D65 are related by a fixed 3×3 matrix from CSS Color 4 §15.1. XYZ D65 and OKLAB are related by two matrices and a cube-root step (the LMS cone-response stage, per Ottosson 2020). OKLAB and OKLCH are related by a Cartesian-to-polar transform — `C = sqrt(a² + b²); H = atan2(b, a)`. HEX is just sRGB serialized as `#RRGGBB` base-16. RGB ↔ HSL, RGB ↔ HSV, RGB ↔ HWB are direct geometric transforms within sRGB, defined in CSS Color 4 §5-7. CMYK is the naive sRGB-based formula above. The whole pipeline is a directed graph rooted at OKLCH internally; every other format is computed from it on every keystroke.
Beyond the core conversion, this tool ships features the legacy generation didn't. **Display P3 and Rec.2020 gamut detection** — three badges flag whether the current color falls inside each space's reproducible range, with a one-click **Snap to sRGB** button that uses binary chroma reduction (per CSS Color 4's informative algorithm) to shrink the color until it fits. **WCAG 2 + APCA Lc dual contrast badges** — both metrics displayed in one row so you can pass the regulatory standard today and sanity-check with the forward-looking perceptual metric. **8 color-blindness simulations** — protanopia, deuteranopia, and tritanopia via the Brettel-Viénot-Mollon 1997 dichromacy matrices; protanomaly, deuteranomaly, and tritanomaly via Machado-Oliveira-Fernandes 2009 anomalous-trichromacy matrices at severity 0.66; achromatopsia and partial achromatomaly via rec601 luminance weights. **OKLCH-uniform palette generation** — tints, shades, tones, and harmonies built by stepping the L channel in equal increments while holding C and H fixed (the same construction as Tailwind v4's default palette). **CSS / Tailwind v4 / SwiftUI / Compose / Flutter code snippets** — paste-ready output for the five platforms most cross-team teams target. **EyeDropper API integration** on Chromium browsers (Chrome, Edge, Brave, Opera) for picking colors anywhere on screen including outside the browser. **URL hash state** — the current color encodes into the URL as `#hex=...` or `#oklch=...` so you can share a live link to the exact color with one copy.
Everything in this tool runs locally in your browser. Your color values are never uploaded, never logged, never analyzed, never persisted on a server. Zero network requests as you type — open the browser DevTools Network tab and watch: typing in any field triggers no traffic at all. This makes the tool safe for unannounced brand palettes, internal design-token systems, draft mockups, and any other confidential color work. No cookies record what you paste; no analytics fire on color changes. The same posture extends to the URL hash: the `#hex=...` fragment lives only in your address bar and is never transmitted to the server (browsers don't include the fragment in HTTP requests), so even a shared link doesn't leak the color to any third party other than the recipient you sent it to. For teams handling pre-launch brand work, embargoed campaigns, or client palettes under NDA, this matters more than the convenience headline suggests. For a deeper dive into why OKLCH became the design-system standard in 2024–2026, read our companion guide: OKLCH color space explained — why Tailwind v4 adopted it.
```
// sRGB → linear → XYZ D65 → OKLAB → OKLCH
// References: W3C CSS Color 4 §11-15, Ottosson 2020 (https://bottosson.github.io/posts/oklab/)
// Worked example: #3b82f6 (Tailwind blue-500)
const srgb = [0x3b, 0x82, 0xf6].map(v => v / 255); // [0.231, 0.510, 0.965]
const toLinear = (v) => v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
const lin = srgb.map(toLinear); // gamma-decoded linear-sRGB
// linear-sRGB → XYZ D65 (CSS Color 4 §15.1 matrix)
const [lr, lg, lb] = lin;
const x = 0.4124564 * lr + 0.3575761 * lg + 0.1804375 * lb;
const y = 0.2126729 * lr + 0.7151522 * lg + 0.0721750 * lb;
const z = 0.0193339 * lr + 0.1191920 * lg + 0.9503041 * lb;
// XYZ D65 → LMS (Ottosson 2020 matrix), cube-root, → OKLAB
const l_ = Math.cbrt(0.8189330101 * x + 0.3618667424 * y - 0.1288597137 * z);
const m_ = Math.cbrt(0.0329845436 * x + 0.9293118715 * y + 0.0361456387 * z);
const s_ = Math.cbrt(0.0482003018 * x + 0.2643662691 * y + 0.6338517070 * z);
const L = 0.2104542553 * l_ + 0.7936177850 * m_ - 0.0040720468 * s_;
const a = 1.9779984951 * l_ - 2.4285922050 * m_ + 0.4505937099 * s_;
const b = 0.0259040371 * l_ + 0.7827717662 * m_ - 0.8086757660 * s_;
// OKLAB → OKLCH (Cartesian to polar)
const C = Math.sqrt(a * a + b * b);
const H = (Math.atan2(b, a) * 180 / Math.PI + 360) % 360;
console.log(`oklch(${L.toFixed(3)} ${C.toFixed(3)} ${H.toFixed(1)})`);
// → oklch(0.629 0.193 263.4)
```
#### FAQ
**Q: How do I convert a hex code to RGB?**
A: Split the 6-digit hex into three 2-digit pairs, then read each pair as a base-16 number from 0-255. `#FF5733` becomes R=`FF`=255, G=`57`=87, B=`33`=51, giving `rgb(255, 87, 51)`. 3-digit shorthand (`#F73`) expands by doubling each digit: `#F73` → `#FF7733`. This tool does the conversion live as you type — paste any hex (with or without the `#`, 3-digit or 6-digit, 4-digit or 8-digit with alpha) and the RGB field updates instantly.
**Q: Is hex the same as RGB?**
A: They encode the same information in different notation. Both describe a color as three channels (red, green, blue) on the 0-255 scale, anchored to the sRGB color space. Hex packs the three channels into a 6-character base-16 string (`#FF5733`); the `rgb()` function spells them out in decimal (`rgb(255, 87, 51)`). They round-trip losslessly. The differences are practical: hex is shorter and fits in a CSS variable comfortably, `rgb()` accepts a separate alpha channel via `rgba()` and supports CSS Color 4 percentage syntax.
**Q: How do you read a hex color code?**
A: A hex color has 6 hexadecimal digits after the `#`, grouped as **RR GG BB**. Each pair encodes one channel from `00` (none) to `FF` (full, 255 in decimal). `#FF0000` is pure red, `#00FF00` is pure green, `#0000FF` is pure blue. An 8-digit hex (`#FF5733CC`) adds an alpha pair at the end — `CC` = 204/255 ≈ 80% opacity. The 3-digit shorthand (`#F73`) expands each digit by duplicating it: `#F73` is identical to `#FF7733`.
**Q: What is the formula for hex to RGB?**
A: For each 2-digit hex pair, multiply the first digit by 16 and add the second: `FF` = 15×16 + 15 = 255, `57` = 5×16 + 7 = 87, `33` = 3×16 + 3 = 51. In JavaScript: `parseInt('FF', 16)` returns 255. In CSS the reverse direction is built into the parser — `rgb(255 87 51)` and `#FF5733` are interchangeable anywhere a ` & ©'
decodeHtml('<>'); // → '<>'
decodeHtml('😀'); // → '😀'
decodeHtml('© 2026'); // → '© 2026' (lenient, no semicolon)
// ---------------------------------------------------------------
// SECURITY: decoded text is unescaped. Never do this with untrusted input:
// el.innerHTML = decodeHtml(userInput); // ❌ reopens the XSS hole
// If the decoded value must be displayed, re-escape it in its destination context first,
// or assign it as text:
// el.textContent = decodeHtml(userInput); // ✅ shown as literal text
// ---------------------------------------------------------------
// Node.js (no DOM) — use a tested library such as he:
// import { decode } from 'he';
// decode('<div> & ©'); // → '
& ©'
```
#### FAQ
**Q: Is my text sent to your server when I decode it?**
A: No. Every entity is resolved entirely in your browser with JavaScript — open DevTools → Network and you will see zero requests fire when you type or paste. Nothing is uploaded, nothing is logged, nothing is written to disk. That privacy matters because the escaped strings people decode are often sensitive: a fragment pulled from a private database, an internal email, a customer record, or markup copied out of an application you do not want leaking. On a server-side decoder every one of those would travel across the network to a machine you do not control; here the text never leaves the tab. This is the whole reason to decode HTML client-side rather than paste it into a website that could, in principle, keep a copy of everything it processes.
**Q: What does it mean to decode or unescape HTML?**
A: Decoding HTML — also called unescaping — is the reverse of HTML escaping: it takes character references like <, &, <, or © and converts each back into the real character it stands for (<, &, <, ©). You reach for it whenever you have a string that was stored or transmitted in its escaped form and you need the literal text back — to read it, edit it, feed it to another program, or debug why a page is showing < on screen instead of <. If you want to go the other way and turn characters into entities, use the companion HTML Entity Encoder; the two are exact inverses.
**Q: Which kinds of entities can this decoder handle?**
A: All three forms, in any mix. It resolves named references (<, &, ©, — and the full HTML5 named-entity set), decimal numeric references (<, é), and hexadecimal numeric references (<, é). It also reconstructs astral-plane characters above U+FFFF from their numeric references, so an emoji like 😀 decodes correctly to 😀. And it follows the browser's lenient parsing for a handful of legacy named entities that omit the trailing semicolon — © 2026 still decodes to © 2026 — which strict parsers would skip. In short, whatever an encoder produced, this decoder reverses it.
**Q: Why does my text show < instead of HTML Entity Encoder again first.
**Q: Does decoding handle non-ASCII characters and emoji correctly?**
A: Yes. Numeric references can encode any Unicode code point, and the decoder resolves them all — accented letters (é → é), symbols (€ → €), em dashes (— → —), and full-plane emoji (😀 → 😀). For astral characters above U+FFFF it reconstructs the complete code point rather than producing a broken half-character. Raw non-ASCII characters that are already in the input pass through untouched, so a string that mixes real UTF-8 with entities decodes cleanly without corrupting either part. Make sure the page or file you paste the result into is served as UTF-8 so the recovered characters display correctly.
**Q: How do I encode text back into entities?**
A: Use the companion HTML Entity Encoder. It takes raw characters like <div> & © and escapes them to <div> & ©, with options for named, decimal, or hex output and an "encode all non-ASCII" mode for legacy charsets. Encoding and decoding are exact inverses for the reserved characters, so you can round-trip text through both tools without loss. You can jump straight there with the Swap direction button on this page.
**Q: Is this the same as URL decoding or Base64 decoding?**
A: No — they are three different encodings for three different jobs, and mixing them up is a common source of bugs. HTML entity decoding turns < back into <. URL (percent) decoding turns %20 back into a space and is for query strings and paths — use the URL Encoder / Decoder for that. Base64 decoding turns a base64 string back into the original bytes and is for binary-safe transport — use Base64 Encode / Decode. A value can be wrapped in more than one of these, so decode them in the reverse order they were applied. This tool handles HTML entities only.
---
### Free HTML Entity Encoder — Escape HTML
URL: https://go-tools.org/tools/html-entity-encode
Encode HTML entities and escape special characters (< > & " ') online — free, no signup, 100% in your browser. Named, decimal, or hex output; never uploaded.
#### What is HTML entity encoding?
HTML entity encoding — also called HTML escaping — is the process of replacing characters that have special meaning in HTML with a safe textual representation called an entity, so the browser displays them as literal text instead of interpreting them as markup. The five characters that matter most are the ones HTML uses to structure a document: the angle brackets < and > that open and close tags, the ampersand & that begins an entity, and the quotation marks " and ' that delimit attribute values. When any of these appears in content that should be shown rather than executed, it must be escaped, or the browser will misread the page — at best your text renders wrong, at worst an attacker slips in a <script> tag.
It helps to be precise about what this tool does. It encodes text into entities; it does not assemble or pretty-print a document. If you want to read a string of code on a page as plain text, or you are inserting user-supplied input into your HTML and need to neutralise it, this is the right tool. If instead you want to indent and tidy existing markup, that is the job of the HTML Formatter; and to turn entities back into characters, use the HTML Entity Decoder.
There are three ways to write any entity, and they are interchangeable. A named reference uses a human-friendly label (< for <, © for ©); a decimal numeric reference writes the character's Unicode code point in base 10 (< for <); and a hexadecimal reference writes the same code point in base 16 (< for <), matching the U+XXXX notation of the Unicode standard. Named entities read best but exist only for characters that have a defined name; numeric entities can represent any code point, which is why they are the safe fallback. The table below lists the entities you will reach for most often:
| Character | Named | Decimal | Hex |
|-----------|-------|---------|-----|
| < | < | < | < |
| > | > | > | > |
| & | & | & | & |
| " | " | " | " |
| ' | ' | ' | ' |
| (space) | |   |   |
| © | © | © | © |
| ® | ® | ® | ® |
| ™ | ™ | ™ | ™ |
| € | € | € | € |
| £ | £ | £ | £ |
| — | — | — | — |
| – | – | – | – |
| … | … | … | … |
| é | é | é | é |
Note that the apostrophe is written ' (or ') rather than ': the named ' was only standardised in HTML5 and XML and is unsafe in older HTML4 parsers, so the numeric form — understood everywhere — is the compatible choice. This tool follows the same convention as the widely used he library, which is why the default output for ' is '.
The distinction between a character set and an entity is worth holding onto, because it explains the "Encode all non-ASCII" option. A charset (like UTF-8) determines how characters are stored as bytes; an entity is a way to write a character using only the plain ASCII characters & # ; and letters or digits. On a modern UTF-8 page, é, —, and 😀 are valid raw characters and need no entity at all — which is why the default mode leaves them alone. You only force them into entities when the text must pass through a system that cannot handle raw UTF-8, in which case every non-ASCII code point is rewritten as an ASCII-safe numeric or named reference. And because all of this runs in your browser, the markup you escape — even a private template or an unpublished draft — never crosses the network. For related conversions, the JSON Escape and Base64 Encode / Decode tools handle escaping for JavaScript strings and binary-safe transport respectively.
```
// Server-side templates auto-escape, but when you build HTML by hand you must escape yourself.
// The five reserved characters and their safe entities:
// < → < > → > & → & " → " ' → '
// Node.js — escape untrusted input before inserting it into HTML element content.
function escapeHtml(str) {
return str
.replace(/&/g, '&') // & first, so later entities are not double-escaped
.replace(//g, '>')
.replace(/"/g, '"')
.replace(/'/g, '''); // numeric form — safe in HTML4, HTML5 and XML
}
const userInput = `Tom & Jerry's`;
const safe = escapeHtml(userInput);
// → <a href="x">Tom & Jerry's</a>
document.getElementById('out').innerHTML = `
Markdown out:
## Pricing
Plans start at **$9/mo**. See the [details](https://example.com/pricing).
| Plan | Price |
| ---- | ----- |
| Pro | $9 |
```
#### FAQ
**Q: How are inline vs reference links handled?**
A: You choose with the Links radio. Inline style writes each anchor as [text](url) right where it appears — compact and obvious for one or two links per paragraph. Reference style writes [text][1] in the prose and collects all the URLs as [1]: https://… definitions at the bottom of the document, which keeps text with many links readable and lets you reuse a URL by label. Both produce identical rendered output; it is purely a source-readability choice. Images follow the same rule: an <img> becomes  inline or ![alt][1] in reference mode.
**Q: ATX vs Setext headings — which should I use?**
A: ATX headings prefix the line with hashes — # H1, ## H2, ### H3 — and work for all six levels. Setext headings underline the text instead: a row of = under a line makes it an H1, a row of - makes it an H2. The catch is that Setext only exists for levels 1 and 2, so this converter emits Setext for <h1>/<h2> and automatically falls back to ATX for <h3> and deeper. ATX is the more common, more portable choice and is easier to grep; pick Setext only if a downstream style guide or linter requires it.
**Q: What happens to HTML that Markdown can't represent, like <div> and <span>?**
A: Markdown has no syntax for generic containers, so structural wrappers such as <div>, <span>, <section>, and <article> are unwrapped — their text and child elements are kept, but the tag itself disappears because there is nothing in Markdown to map it to. Class names, id attributes, inline style attributes, and data-* attributes are dropped for the same reason: Markdown carries no way to express them. When an element genuinely has no Markdown equivalent and dropping it would lose meaning, the converter leaves it as raw inline HTML rather than silently deleting the content. This is by design — see the question on whether the conversion is lossless.
**Q: Does it strip <script> and styles?**
A: Yes. <script> and <style> elements, along with their contents, are removed entirely — they are code and CSS, not document content, and have no place in Markdown. The same goes for <link>, <meta>, and other head-level elements when you paste a whole page. Inline event handlers like onclick and CSS in style attributes are dropped as well. The result is text content only, which is exactly what you want when the Markdown is headed for a docs repo, a static-site generator, or an LLM context window. If you need the styling preserved, Markdown is the wrong target format.
**Q: How are nested tables and lists handled?**
A: Nested lists convert cleanly: each level of <ul>/<ol> nesting becomes two spaces of indentation, and ordered lists are renumbered from 1. Tables are trickier. GitHub Flavored Markdown pipe tables are flat by specification — a table cell cannot contain another table, and it cannot contain block elements like lists or multiple paragraphs. So a simple <table> converts to a clean pipe table, but a table with a nested table inside a cell, or with block content in cells, degrades: the converter flattens what it can and falls back to leaving the complex parts as raw HTML so no data is lost. Deeply nested layout tables from legacy pages are the worst case — consider simplifying the HTML first.
**Q: Is HTML to Markdown lossless?**
A: No, and it is important to be honest about that. HTML is far more expressive than Markdown: it has hundreds of elements and arbitrary attributes, while Markdown covers a small, deliberate set — headings, emphasis, lists, links, images, code, blockquotes, and (with GFM) tables, task lists, and strikethrough. Anything outside that set has no representation: colspans, custom attributes, inline styles, <div>/<span> structure, and most semantic wrappers are dropped or preserved only as raw HTML. Converting HTML → Markdown → HTML will not reproduce the original byte-for-byte. The conversion is lossy on purpose — the goal is clean, portable, human-editable text, not a faithful round-trip. To go back the other way, use our Markdown to HTML converter.
**Q: Can I feed the Markdown to an LLM or ChatGPT?**
A: Yes — this is one of the best modern uses. Raw HTML wastes tokens on tags, attributes, scripts, and styling that a model does not need, and the noise can degrade retrieval quality in a RAG pipeline. Converting a page to Markdown strips that overhead while keeping the structure a model reads well: headings become hierarchy, lists stay lists, tables stay tables, and links stay links. The output is typically a fraction of the original HTML's token count, so you fit more real content in the context window. Paste a scraped page here, copy the Markdown, and drop it into your prompt, embedding step, or document store.
**Q: Are my files uploaded to a server?**
A: No. The conversion runs entirely in your browser: the HTML is parsed into a DOM and serialised to Markdown locally with JavaScript, and nothing is transmitted, stored, or logged. You can confirm it by opening your browser's Network tab — converting triggers zero network requests. That makes the tool safe for internal CMS exports, unpublished pages, customer content, and anything under NDA. There is no upload step and no size limit beyond what your browser can comfortably hold in memory.
**Q: Does it work offline?**
A: Yes, once the page has loaded. The DOM parser and the Markdown serialiser both run in the browser with no server round-trip, so you can convert with your network disconnected — on a plane, behind a strict firewall, or any time you would rather a page never left your machine. This falls straight out of the privacy-first design: because nothing is sent anywhere, there is nothing the tool needs the network for after the initial load.
**Q: Can I convert Markdown back to HTML?**
A: Yes. Switch to the Markdown → HTML tab, or open the dedicated Markdown to HTML converter, paste your Markdown, and get rendered HTML with a live preview, full GFM support, and fragment, full-document, or email-inline output. The two directions pair up: use HTML → Markdown to pull existing web content into a Markdown workflow, and Markdown → HTML to publish or preview it. If the source HTML is messy, our HTML Formatter can tidy it before you convert.
---
### htpasswd Generator — bcrypt, Apache MD5 (apr1) & Basic Auth
URL: https://go-tools.org/tools/htpasswd-generator
Generate htpasswd entries with bcrypt, Apache MD5 (apr1), SHA-1 & more. Get ready-to-paste Apache, nginx & Docker config. 100% in your browser — no upload.
#### What Is an htpasswd File?
An 
/* CSS */
.badge {
background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==");
}
// JSON
{ "mime": "image/png", "data": "iVBORw0KGgo…" }
```
#### FAQ
**Q: What does this Image to Base64 converter do?**
A: It reads an image you drop, paste, or select and encodes its bytes as a Base64 string — entirely inside your browser. You get the raw Base64, a ready-to-use data URI (data:image/png;base64,…), and copy-paste snippets for HTML ![]()
, CSS background-image, Markdown, and JSON. A metadata bar reports the original file size, the encoded size, the exact percentage increase (Base64 is about 33% larger), the pixel dimensions, and the MIME type. Nothing is uploaded: the encoding runs locally via the FileReader API, so the same tool is safe for screenshots, internal assets, and unreleased artwork. To go the other way, use the Base64 → Image tab or our Base64 to Image decoder.
**Q: Are my images uploaded to a server?**
A: No. Every step happens client-side in your browser using the FileReader API and JavaScript string encoding. Your image is never transmitted, never stored, and never logged. You can confirm this by opening your browser's Network tab — encoding an image triggers zero network requests. This makes the tool safe for sensitive material: product screenshots before launch, internal diagrams, customer assets, and anything under NDA. There is no file-size cap imposed by an upload limit, only the practical limit of how large a Base64 string your browser and target system can comfortably handle.
**Q: How much bigger does Base64 make an image?**
A: Base64 encodes every 3 bytes of binary data as 4 ASCII characters, so the encoded string is roughly 33% larger than the original file (plus a few bytes of padding and the data: prefix). A 9 KB PNG becomes about 12 KB of text. This overhead is the single most important reason not to Base64 large images: you ship more bytes and, because the string is embedded in your HTML or CSS, those bytes are re-downloaded every time the containing file changes and cannot be cached independently. The tool shows the exact increase for your specific file in the metadata bar so you can make the call with real numbers.
**Q: When should I use a Base64 image instead of a normal file?**
A: Base64 (as a data URI) is a good fit for small, rarely-changing assets where avoiding a separate HTTP request matters more than caching: tiny icons and logos inlined in CSS, images embedded in HTML email (many clients block external images but render data URIs), single-file widgets or bookmarklets that must be self-contained, SVG sprites, and images stored inside JSON/API payloads. A practical rule of thumb: under about 2 KB and used on one or two pages, inlining usually wins. The advice badge in this tool encodes exactly that heuristic — green under 2 KB, amber up to 10 KB, red above.
**Q: When should I NOT use Base64 images?**
A: Avoid Base64 for anything large or reused across pages. Four concrete reasons: (1) the ~33% size increase means more bytes over the wire; (2) an inlined image cannot be cached on its own — it is re-downloaded with every change to the HTML or CSS that contains it, and repeated on every page that embeds it; (3) decoding a large data URI costs CPU and battery, which is noticeable on mobile; and (4) you lose responsive images (srcset/sizes) and lazy-loading. Since HTTP/2 multiplexes many small requests cheaply, the original reason to inline — cutting request count — rarely applies anymore. For photos, hero images, or anything over ~10 KB, a normal cached file almost always loads faster. If the goal is a smaller file, run it through our Image Compressor first.
**Q: How do I use the Base64 output in HTML and CSS?**
A: For HTML, switch to the HTML tab and paste the generated element: 
. For CSS, use the CSS tab, which wraps the data URI in background-image: url("data:image/png;base64,…"). Both work anywhere a URL is accepted — img src, CSS background, mask-image, even favicon link tags. The data: scheme is supported by every modern browser. One caveat: very long data URIs in inline HTML can hurt readability and, in CSS, bloat the stylesheet that ships to every visitor, so reserve inlining for genuinely small assets.
**Q: Which image formats are supported?**
A: PNG, JPEG/JPG, GIF (including animated), WebP, SVG, ICO, and BMP are all supported, plus AVIF where the browser can decode it. Because the tool encodes the raw bytes rather than re-rendering the image, animated GIFs stay animated, transparent PNGs keep their alpha channel, and SVGs remain fully scalable. The MIME type is read from the file itself and, when you paste raw Base64 into the decoder, inferred from the data's magic bytes. There is no format conversion during encoding — the output represents exactly the file you provided.
**Q: Why is SVG a special case?**
A: SVG is XML text, not binary, so Base64 actually makes it larger and harder to read for no benefit. For inlining SVG in CSS or HTML, URL-encoding the markup (percent-encoding a handful of characters like #, <, >, and quotes) is usually smaller than Base64 and keeps the source legible and gzip-friendly. This tool still offers Base64 SVG output because some pipelines require it, but if you are hand-optimizing CSS, prefer a URL-encoded data URI. Our URL Encoder/Decoder helps with that approach.
**Q: Is Base64 the same as encryption?**
A: No. Base64 is an encoding, not encryption — it is fully reversible by anyone with no key required. It exists to represent binary data using a safe set of printable ASCII characters so the data survives transport through systems that only handle text (HTML, JSON, email headers, URLs). Anyone can decode a Base64 string back to the original image in seconds, including with the Base64 → Image tab here. Never treat Base64 as a way to hide or protect sensitive image content; it provides zero confidentiality.
**Q: Can I embed a Base64 image in an email?**
A: Yes, and it is one of the better uses of the technique. Many email clients block externally hosted images by default for privacy, which breaks layouts that rely on remote logos. Embedding small images as data URIs ensures they render immediately without a server fetch. The trade-offs: some older clients (notably certain versions of Outlook) have spotty data-URI support, and large embeds inflate the message size that every recipient downloads. Keep embedded images small — logos and icons, not photographs — and test across your target clients.
**Q: Why does my Base64 image not render?**
A: The most common causes: a missing or wrong MIME type in the data: prefix (use image/png for PNG, image/jpeg for JPG, image/svg+xml for SVG), whitespace or line breaks accidentally inserted into the string, a truncated copy that dropped the trailing padding (= or ==), or pasting only the raw Base64 without the data:…;base64, prefix where a URL is expected. The decoder in this tool is tolerant — it strips whitespace, accepts input with or without the prefix, and infers the MIME from the image's magic bytes — so pasting your string into the Base64 → Image tab is the fastest way to confirm whether the data itself is valid.
---
### JavaScript Formatter & Minifier
URL: https://go-tools.org/tools/js-formatter
Format, beautify and minify JavaScript instantly in your browser. Clean up messy code or compress it with Terser to ship — free, private, and your code never leaves your device.
#### What is JavaScript Formatting?
JavaScript formatting (also called beautifying or pretty-printing) rewrites code with consistent indentation, spacing and line breaks so it's easy to read and review. The code behaves identically before and after — only whitespace changes. Minifying does the reverse: it shortens names, drops comments and collapses whitespace to produce the smallest bundle that runs the same. This tool does both, entirely in your browser.
#### FAQ
**Q: How do I format JavaScript online?**
A: Paste your code into the input box and click Format. The tool reindents it with consistent spacing and line breaks, then lets you copy it. Everything runs locally in your browser — nothing is uploaded.
**Q: How do I minify JavaScript?**
A: Paste your code and click Minify. The tool runs Terser to rename locals, remove comments and collapse whitespace into the smallest equivalent script, and shows how many bytes you saved.
**Q: What is the difference between formatting and minifying JavaScript?**
A: Formatting (beautifying) adds indentation and spacing to make code readable. Minifying shortens names and strips whitespace and comments to shrink the bundle for faster loading. Both run with the same behavior as the original.
**Q: Does minifying change what my code does?**
A: No. Terser preserves behavior — it only renames local variables and removes whitespace, comments and unreachable code. The minified script runs the same as the source.
**Q: Is my code safe with this tool?**
A: Yes. All formatting and minifying happen locally in your browser using JavaScript — your code is never sent to any server, logged, or stored. That makes it safe for proprietary or unreleased code, unlike server-side tools that receive a copy of everything you paste.
**Q: Why did minify report an error?**
A: Terser needs syntactically valid JavaScript. If you paste an incomplete snippet or TypeScript/JSX, parsing fails — format works on a best-effort basis, but minification requires valid JS. Fix the syntax or transpile first, then try again.
**Q: What indentation should I use for JavaScript?**
A: Two spaces is the most common default in modern JavaScript and keeps diffs compact; four spaces and tabs are also widely used. Pick one and apply it consistently — this tool supports all three when beautifying.
---
### JSON Diff & Compare
URL: https://go-tools.org/tools/json-diff
Compare two JSON files instantly in your browser. Side-by-side highlighting, RFC 6902 JSON Patch output, ignore noisy fields like timestamps and IDs. 100% private, no upload.
#### What is JSON Diff?
JSON Diff is a structural comparison of two JSON documents that respects JSON's data model — keys are unordered, types are strict, and arrays may be ordered or keyed. Unlike a text diff (which compares lines and reports key reorders or whitespace as differences), a JSON diff produces semantically meaningful results.
The canonical machine-readable form is JSON Patch (RFC 6902), an ordered ops array (add, remove, replace, move, copy, test) that transforms one document into another. Paths use JSON Pointer (RFC 6901). Closely related: JSON Merge Patch (RFC 7396) — simpler but cannot distinguish 'remove key' from 'set key to null'. This tool outputs RFC 6902.
Deep equality on JSON in JavaScript is harder than it looks. JSON.stringify(a) === JSON.stringify(b) fails on key reorder, misleads on -0 vs 0 (both stringify to "0"). A correct diff must walk both trees in parallel using key-set union, distinguish null from missing via the 'in' operator, and decide what 'equal' means for numbers (Object.is by default, epsilon for tolerance).
This tool runs entirely in your browser. Inputs never leave your machine. Safe for API responses, internal schemas, and proprietary configs.
Working with adjacent JSON tools? Format with JSON Formatter; convert with JSON to YAML, YAML to JSON, JSON to CSV, and CSV to JSON. See our guide for advanced timestamp/ID filtering patterns. Need to validate the structure (not just diff it)? See our JSON Schema validation guide.
```
// Two JSON documents that look different but are semantically equal
const a = '{"a":1,"b":2}';
const b = '{"b":2,"a":1}';
// Naive comparison — wrong
JSON.stringify(JSON.parse(a)) === JSON.stringify(JSON.parse(b));
// → false (key order differs)
// JSON Diff (this tool) — correct: key order is irrelevant
// → 0 differences
// JSON Patch (RFC 6902) for { "a": 1 } → { "a": 2 }
// [{ "op": "replace", "path": "/a", "value": 2 }]
```
#### FAQ
**Q: Why does my diff show everything changed when I only changed one field?**
A: Three usual suspects: (1) different key order — JSON Diff treats key order as equivalent, but text diff tools don't; (2) timestamps/UUIDs/auto-IDs that mutate on every request — add them to Ignore paths; (3) array order, when by-index comparison shouldn't apply — switch Array mode to 'Match by key'.
**Q: How do I ignore timestamps and IDs in JSON diff?**
A: Use the Ignore paths input above. Click the 'Timestamps' or 'IDs' preset for one-click filtering of /createdAt, /updatedAt, /*Id, /*At, /requestId. You can also paste your own Extended JSON Pointer patterns — one per line — for advanced filtering.
**Q: What's the difference between JSON Patch and a visual diff?**
A: Visual (side-by-side) diff is for humans — review changes by eye. JSON Patch (RFC 6902) is for machines — a structured ops array (add/remove/replace) you can apply with fast-json-patch or rfc6902 npm packages. Same diff, two outputs.
**Q: Does JSON diff treat null and missing keys the same?**
A: No. {"a":null} and {} differ — the first has an explicit null, the second has no key. Real systems behave differently for the two; this tool keeps them distinct.
**Q: How are arrays compared — by index or by key?**
A: By index (Sequential) by default. Switch to 'Match by key' and provide a key field (commonly id) to align elements regardless of order. Use this for K8s envs, package-lock entries, or any list that's logically a set.
**Q: Can I export the diff as RFC 6902 JSON Patch?**
A: Yes. The JSON Patch tab outputs a valid RFC 6902 ops array. If Ignore paths are set, the patch is filtered (the tab shows '(filtered: excludes N ignored paths)') and will not round-trip the originals exactly. Clear Ignore paths for a complete patch.
**Q: Is JSON Patch the same as JSON Merge Patch (RFC 7396)?**
A: No. RFC 6902 (JSON Patch) is an ordered ops array — explicit and reversible. RFC 7396 (Merge Patch) is a single merge document — simpler but cannot represent removal differently from setting null. JSON Diff outputs RFC 6902.
**Q: How do I compare two large JSON files (>10 MB)?**
A: Files over ~5 MB exceed practical browser memory. Live mode disables at 200 KB; for multi-megabyte files, use command-line jq or fast-json-patch in Node.
**Q: Does the tool send my JSON to a server?**
A: No. All comparison runs locally in your browser. Your JSON inputs are never written to disk, network, localStorage, or URL parameters. Only your preferences (ignore paths, array mode, numeric tolerance, active tab) are stored in localStorage so they persist across sessions. Refreshing the page clears the JSON inputs. The Share Link button writes only your config (Array mode, Ignore paths) — never your data.
**Q: Why does 42 differ from "42" in the diff?**
A: JSON Diff is type-strict: number 42 and string "42" are not equal. This catches backend serialization drift (some endpoints return numeric IDs, others return strings) — the diff labels it as 'type' modification.
**Q: Can I diff JSON with comments (JSONC) or trailing commas?**
A: Standard JSON (RFC 8259) does not allow comments or trailing commas. This tool uses native JSON.parse, which rejects both. Strip comments first using JSON Formatter.
**Q: How do I compare nested arrays of objects by a key like id?**
A: Set Array mode to 'Match by key' and enter id. Diff aligns by id values. v1 applies the same key field at every array depth; inner arrays without that field fall back to sequential and emit a warning chip.
**Q: Does the diff handle floating-point precision (0.1 + 0.2)?**
A: Yes, with Numeric tolerance. Default is 0 with Object.is — so -0 vs +0 are flagged. Set tolerance to a small epsilon (e.g. 1e-9) and 0.1 + 0.2 will compare equal to 0.3. Tolerance applies only to numeric leaves.
---
### JSON Escape
URL: https://go-tools.org/tools/json-escape
Escape any text or JSON into a valid JSON string literal in your browser. Handles quotes, newlines, tabs, Unicode, and slashes. 100% private, no upload, instant.
#### What is JSON Escaping and When Do You Need It?
JSON escaping is the process of converting a raw string into a form that is safe to embed inside a JSON document. JSON has a small set of characters that carry structural meaning — the double quote delimits strings, the backslash starts an escape sequence — plus control characters (newlines, tabs) that are not allowed to appear literally inside a string. Escaping replaces each of these with a safe two-character sequence (\", \\, \n, \t) or a \uXXXX Unicode escape, so the resulting string parses cleanly anywhere.
You reach for JSON escaping more often than you might think. The most common case is JSON-in-JSON: a webhook envelope, a message-queue payload, or an audit log stores a request body as a string field, which means the inner JSON must be escaped before it can be assigned. Another is hand-authoring JSON config: pasting a multi-line shell script, SQL query, or code snippet into a single JSON value requires turning every newline into \n. A third is building REST request bodies by hand in tools like curl, where a quoted JSON string must be escaped to survive the shell and the HTTP layer.
This tool has three differentiators over a naive escaper. First, it is built on the exact JSON specification rules — the same logic a compliant serializer uses — so output round-trips losslessly: escape here, parse anywhere, get your bytes back. Second, the optional ASCII-safe mode converts every non-ASCII character (including astral emoji, handled as surrogate pairs) to \uXXXX for systems that cannot be trusted with UTF-8. Third, everything runs 100% in your browser — your payloads, which often contain PII, tokens, and secrets, never touch a server. To reverse the process, use our JSON Unescape tool; to validate JSON first, see the JSON Formatter.
```
// Input text
She said "hi"
then left.
// Escaped (Wrap on) — identical to JSON.stringify(input)
"She said \"hi\"\nthen left."
// Escaped (Wrap off) — just the body, for hand-built JSON
She said \"hi\"\nthen left.
// JSON-in-JSON
{"a":1} -> "{\"a\":1}" -> {"payload": "{\"a\":1}"}
```
#### FAQ
**Q: What does this JSON escape tool do?**
A: It converts any text — a JSON object, a code snippet, a log line, or plain prose — into a valid JSON string literal, entirely in your browser. Special characters that would break a JSON document are escaped: double quotes become \", backslashes become \\, newlines become \n, tabs become \t, carriage returns become \r, and other control characters become \uXXXX. The result is a string you can safely paste as a value inside a JSON document, a REST request body, a configuration file, or a database column. Nothing is uploaded — the conversion runs 100% client-side, so it is safe for payloads containing PII, secrets, or internal data.
**Q: What is the difference between JSON escape and JSON stringify?**
A: They describe the same core operation from two angles. JSON.stringify() in JavaScript takes a value and produces its JSON text representation; when the value is a string, that means wrapping it in double quotes and escaping the special characters inside — which is exactly JSON escaping. This tool does precisely that: with Wrap in double quotes on, the output equals JSON.stringify(yourText); with it off, you get the escaped body without the surrounding quotes, which is what you need when you are building the JSON by hand and already typed the quotes. So if you searched for json stringify online, this is the tool — it gives you both the quoted and unquoted forms.
**Q: Is my data uploaded anywhere?**
A: No. All escaping runs entirely in your browser using JavaScript — your text is never transmitted, stored, logged, or analyzed on any server. This makes the tool safe for API payloads with PII, authentication tokens, internal configuration, and production secrets. You can verify it in your browser's Network tab: typing or pasting triggers zero network requests. There are no cookies for your input and no third-party analytics that capture what you paste.
**Q: When do I need the \uXXXX (escape non-ASCII) option?**
A: JSON allows raw UTF-8, so by default an é stays an é and an emoji stays an emoji — perfectly valid and more readable. Turn on Escape non-ASCII only when a downstream system cannot be trusted with UTF-8: old SOAP/XML gateways, some logging pipelines, email headers, or source files that must stay pure ASCII. With it on, every character above U+007F becomes a \uXXXX sequence (astral characters like emoji become a surrogate pair, e.g. 😀 → \ud83d\ude00). The escaped output is byte-for-byte ASCII and decodes back to the original Unicode in any compliant JSON parser.
**Q: How do I embed a JSON object inside another JSON string (JSON-in-JSON)?**
A: Paste the inner JSON into the input, keep Wrap in double quotes on, and copy the result — it is now a single escaped string you can assign to a key in the outer document. For example {"a":1} becomes "{\"a\":1}", which you place after a colon: {"payload": "{\"a\":1}"}. This double-encoding is common in webhook envelopes, message-queue payloads, and audit logs that store a request body as a string. To reverse it and read the inner object, use our JSON Unescape tool.
**Q: What does the Escape forward slash (\/) option do?**
A: The forward slash / is a normal character in JSON and does not require escaping, so it is left alone by default. The option exists for one specific case: embedding JSON inside an HTML <script> tag, where the sequence </script> would prematurely close the tag. Escaping / to \/ turns </script> into <\/script>, which is still valid JSON but no longer a tag terminator. Enable it only when you are inlining JSON into HTML; for every other use, leave it off for cleaner output.
**Q: Does it handle newlines, tabs, and control characters correctly?**
A: Yes. The tool is built on the JSON specification's exact escaping rules: newline → \n, carriage return → \r, tab → \t, backspace → \b, form feed → \f, double quote → \", backslash → \\, and any remaining control character below U+0020 → \uXXXX. This is identical to what a compliant JSON serializer produces, so the output round-trips losslessly: escape it here, parse it anywhere, and you get your original text back byte for byte.
---
### JSON Formatter & Validator
URL: https://go-tools.org/tools/json-formatter
Format, validate and beautify JSON instantly in your browser. Free online tool with syntax validation, error detection, minify and one-click copy. 100% private.
#### What is JSON?
JSON (JavaScript Object Notation) is a lightweight, text-based data interchange format that is easy for humans to read and write, and easy for machines to parse and generate. Standardized as RFC 8259 and ECMA-404, JSON has become the universal standard for data exchange across virtually all programming languages, APIs, and web services.
As Douglas Crockford, the creator of JSON, wrote on json.org: "JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript." This deliberate simplicity is exactly why JSON won out over XML and became the lingua franca of the modern web.
JSON supports six data types: strings (in double quotes), numbers, booleans (true/false), null, arrays (ordered lists), and objects (key-value pairs) (RFC 8259). Its simplicity and readability have made it the preferred format over XML for most modern web applications, REST APIs, and configuration files. JSON is the most popular data format for APIs, used by 86% of developers (Postman State of API Report 2023).
A JSON formatter transforms raw or minified JSON into a well-structured, indented format that makes the data hierarchy immediately visible. This is essential for debugging API responses, inspecting configuration files, and understanding complex nested data structures. Unlike XML, JSON does not support comments, attributes, or namespaces — it focuses purely on data representation (ECMA-404).
This tool runs entirely in your browser — your JSON data never leaves your device. Unlike server-based formatters, there are no uploads, no logging, and no data retention. Safe to use with API keys, production configs, and proprietary data.
JSON is frequently used with other developer tools. When debugging APIs, you may need to decode Base64-encoded JSON payloads (such as JWT tokens), or generate UUIDs for use as unique identifiers within JSON data structures. Working with JSON5 or JSONC config files? See our JSON5 and JSONC formatting guide for syntax differences, tooling support, and best practices. For a deep dive on YAML's Norway problem and JSON ↔ YAML conversion, read our YAML Norway problem & JSON-YAML differences guide, or convert directly with JSON to YAML and YAML to JSON. Need to compare two JSON documents and find what changed? Try our JSON Diff. To move tabular JSON into a spreadsheet or import a CSV export back into JSON, use JSON to CSV and CSV to JSON.
```
// Format (pretty-print) JSON with 2-space indentation
const raw = '{"name":"Alice","age":30,"active":true}';
const parsed = JSON.parse(raw); // parse string → object
const formatted = JSON.stringify(parsed, null, 2);
console.log(formatted);
// → {
// "name": "Alice",
// "age": 30,
// "active": true
// }
// Minify JSON (strip all whitespace)
const minified = JSON.stringify(parsed);
console.log(minified);
// → '{"name":"Alice","age":30,"active":true}'
```
#### FAQ
**Q: How do I format JSON online?**
A: Paste your raw or minified JSON into the input field above and click "Format JSON." The tool instantly parses your data, validates the syntax, and displays a properly indented version with 2-space indentation. You can then copy the result to your clipboard with one click. Everything runs locally in your browser — no data is sent to any server.
**Q: How do I validate JSON?**
A: Paste your JSON into the input field and click "Format JSON." If the JSON contains syntax errors, the tool displays a detailed error message showing what went wrong and where. If the JSON is valid, it will be formatted and displayed in the output area. This tool validates against RFC 8259, the current JSON standard.
**Q: How do I minify JSON?**
A: Paste your JSON into the input field and click "Minify JSON." The tool removes all unnecessary whitespace, line breaks, and indentation to produce the most compact representation. Minified JSON is ideal for API responses, configuration files in production, and anywhere file size or bandwidth matters.
**Q: Is my JSON data safe when using this tool?**
A: Yes, completely. All processing happens locally in your browser using JavaScript's native JSON.parse() and JSON.stringify() — your data never leaves your device. There are no server uploads, no cookies, no analytics tracking on your input, and no data storage of any kind. This makes it safe to use with API keys, credentials, and proprietary data.
**Q: How do I fix "Unexpected token" errors in JSON?**
A: An "Unexpected token" error means the JSON parser found a character that doesn't belong at that position. The most common causes are: a missing comma between elements ({"name": "Alice" "age": 30}), a trailing comma after the last element ({"name": "Alice",}), or extra characters after the JSON ends. Paste your JSON into this tool to see the exact error location, then check the characters around that position.
**Q: Why does my JSON have a "trailing comma" error?**
A: JSON does not allow a comma after the last element in an object or array. This is one of the most common errors because JavaScript and many other languages permit trailing commas. For example, {"name": "Alice", "age": 30,} is invalid JSON — remove the comma after 30 to fix it. If you frequently copy data from JavaScript code, always check for trailing commas before using it as JSON.
**Q: Can I use single quotes in JSON?**
A: No. JSON requires double quotes for all strings and property keys. Single quotes are valid in JavaScript and Python, but they are not part of the JSON specification (RFC 8259). For example, {'name': 'Alice'} is invalid — it must be {"name": "Alice"}. If you have data with single quotes, this tool will report a syntax error and show you the exact position to fix.
**Q: Can I add comments to JSON?**
A: No, standard JSON does not support comments of any kind — no //, /* */, or # syntax. This was an intentional design decision to keep JSON simple and parseable. If you need comments in configuration files, consider JSONC (JSON with Comments, used by VS Code and TypeScript), JSON5, or YAML. To use commented files as standard JSON, strip the comments before parsing.
**Q: Why is my JSON not parsing correctly?**
A: The most common reasons JSON fails to parse are: (1) trailing commas after the last element, (2) single quotes instead of double quotes, (3) unquoted property keys, (4) comments in the data, (5) missing or extra brackets/braces, (6) unescaped special characters like backslashes or newlines inside strings. Paste your JSON into this tool — it will pinpoint the exact error type and location so you can fix it quickly.
**Q: What is the difference between JSON and YAML?**
A: Both JSON and YAML are data serialization formats, but they differ in design philosophy. JSON uses braces, brackets, and double quotes with a strict syntax — making it ideal for machine parsing and APIs. YAML uses indentation and minimal punctuation — making it more human-readable and popular for configuration files (Docker Compose, Kubernetes, GitHub Actions). JSON is a subset of YAML, so any valid JSON is also valid YAML, but not vice versa.
**Q: What is JSON Schema?**
A: JSON Schema is a separate standard (not part of JSON itself) that defines the expected structure, types, and constraints of JSON data. For example, you can specify that a field must be a string, a number must be between 1 and 100, or an array must contain at least one element. JSON Schema is widely used for API request/response validation, form generation, and documentation. This tool validates JSON syntax, not JSON Schema — for schema validation, use a dedicated JSON Schema validator. For end-to-end validation patterns in Node, Python, and the browser, see our complete JSON Schema validation guide.
**Q: What is the difference between JSON and JSON5?**
A: JSON5 is an extension of JSON that adds features developers frequently request: single and double quotes, trailing commas, comments (// and /* */), unquoted keys, multiline strings, and hexadecimal numbers. JSON5 is often used in configuration files where human editing is common. Standard JSON parsers cannot read JSON5 — you need a JSON5 parser. This tool works with standard JSON (RFC 8259) only.
**Q: What is the maximum size of a JSON file?**
A: The JSON specification itself has no file size limit. Practical limits depend on the parser and environment: browsers typically handle JSON up to 500 MB–1 GB before running into memory issues, while server-side parsers (Node.js, Python, Java) can handle larger files with streaming parsers. This online tool efficiently handles JSON up to about 10 MB. For very large JSON files, consider using command-line tools like jq or streaming parsers.
**Q: I have a large API response that's completely minified — what's the fastest way to make it readable for debugging?**
A: Paste the minified JSON into this tool and click Format JSON. It will instantly parse and pretty-print the data with 2-space indentation, making nested objects and arrays immediately visible. For very large responses (5-10 MB), this browser-based tool is often faster than VS Code or command-line jq because it uses the browser's native JSON.parse() with zero startup overhead. You can also use the keyboard shortcut Ctrl+V to paste and the result appears instantly. For programmatic formatting, use JSON.stringify(data, null, 2) in JavaScript or python -m json.tool from the command line.
**Q: I keep getting JSON parse errors when copying data from my JavaScript code — what am I doing wrong?**
A: The most common cause is that JavaScript object literals are not valid JSON. Three key differences trip people up: (1) JavaScript allows single quotes ('name') but JSON requires double quotes ("name"); (2) JavaScript allows trailing commas ({"a": 1,}) but JSON does not; (3) JavaScript allows unquoted keys ({name: "Alice"}) but JSON requires quoted keys ({"name": "Alice"}). Additionally, JavaScript comments (// or /* */) are not valid in JSON. Paste your data into this tool — it will pinpoint the exact error type and position so you can fix it quickly. If you frequently need to convert JS objects to JSON, consider using JSON5 format as an intermediate step.
---
### JSON Schema Validator
URL: https://go-tools.org/tools/json-schema-validator
Validate JSON against any JSON Schema instantly in your browser. Supports Draft 2020-12, 2019-09, and Draft-07 with path-precise error messages. 100% private — no upload, no account, free.
#### What is a JSON Schema Validator?
A JSON Schema validator is a program that takes two JSON documents — a data document and a schema document — and reports whether the data conforms to the schema's contract. The schema declares field types, required keys, value ranges, allowed enum values, regex patterns, and structural rules using a fixed vocabulary (type, properties, required, items, enum, oneOf, allOf, $ref, format). The validator walks both documents in parallel and emits zero or more errors, each pinned to a JSON Pointer path inside the data.
Validation runs at runtime, at the boundary between untrusted input and your code. TypeScript types vanish at compile time and cannot help with JSON arriving from a webhook, a third-party API, or a user paste — that gap is exactly what JSON Schema fills. Pair it with TypeScript (or Pydantic in Python) and you get compile-time guarantees inside your codebase plus runtime guarantees at the boundary.
Draft 2020-12 is the current spec and what you should pick for new projects in 2026. Earlier drafts (2019-09, Draft-07, Draft-06, Draft-04) survive in legacy codebases — Draft-07 is still common in Helm charts, VS Code settings, and older Ajv configs. OpenAPI 3.1 uses Draft 2020-12 natively; OpenAPI 3.0 uses a Draft 4 subset.
This tool runs entirely in your browser. Your JSON, your schema, and the validation output never leave your machine — safe for proprietary API contracts and sensitive payloads. Internal $ref pointers resolve automatically; external HTTP refs are intentionally disabled to preserve privacy.
Working with adjacent JSON tools? Format the JSON with JSON Formatter before pasting; compare two JSON documents with JSON Diff; convert with JSON to YAML and YAML to JSON. For end-to-end validation in Node, Python, and the browser, see our JSON Schema validation guide.
```
// A 5-line schema that catches three real bugs
const schema = {
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"id": { "type": "integer", "minimum": 1 },
"email": { "type": "string", "format": "email" },
"age": { "type": "integer", "minimum": 0, "maximum": 150 }
},
"required": ["id", "email"],
"additionalProperties": false
};
// Three bugs the schema catches:
const bad = { "id": "42", "age": 200 };
// /id → type: expected integer, got string
// /email → required: missing
// /age → maximum: 200 > 150
// In Node: new Ajv().compile(schema)(bad) // false; ajv.errors has the paths
// In Python: jsonschema.validate(bad, schema)
// In the browser: this tool — same errors, same paths, no install
```
#### FAQ
**Q: What is JSON Schema validation?**
A: JSON Schema validation checks whether a JSON document matches a contract written in JSON Schema syntax. The schema declares field types, required keys, allowed values, and structural rules; the validator walks both documents in parallel and reports any path that violates the contract. It runs at the boundary between untrusted input (API request, webhook, config file, form payload) and your business logic — catching shape errors before they corrupt downstream code. See our complete guide to JSON Schema validation for end-to-end Node, Python, and browser examples.
**Q: Which JSON Schema drafts does this validator support?**
A: Draft 2020-12 (default and recommended), Draft 2019-09, and Draft-07. The validator auto-detects the draft from the schema's $schema URI when present and falls back to your selection from the dropdown otherwise. For new projects in 2026 use Draft 2020-12 — it is what OpenAPI 3.1 uses natively and what Ajv defaults to. Draft-07 remains common in legacy codebases (older AJV setups, Helm charts, VS Code settings).
**Q: How do I validate JSON against a schema?**
A: Paste your JSON data into the left panel and your JSON Schema into the right panel. The validator runs instantly as you type — green check means valid, red list means errors. Each error includes a JSON Pointer path (for example /user/email), the failing keyword (type, required, pattern, minimum), and a human-readable message. Click any error to jump to the offending line. No upload, no signup.
**Q: What's the difference between JSON Schema validation and JSON syntax validation?**
A: JSON syntax validation only confirms the document parses — no extra commas, no missing braces. JSON Formatter handles that. JSON Schema validation runs after parsing and checks whether the parsed structure matches the contract: required fields present, types correct, values within range. You typically run both — format first to confirm parseable, then validate against the schema.
**Q: Why is my schema rejecting JSON that looks correct?**
A: Five usual suspects: (1) additionalProperties: false — your data has a key the schema didn't declare, often a typo or a new field; (2) type: "integer" vs "number" — JSON Schema treats 1.0 as a number, not an integer; (3) format keywords (email, uri, uuid) reject malformed strings even when they look fine; (4) required at the wrong nesting level — required must appear next to properties, not inside one; (5) the JSON has a string "42" where the schema expects integer 42. The error path will pinpoint which one.
**Q: Does this support $ref and remote schema references?**
A: Internal $ref pointers (#/$defs/foo, #/properties/bar) work out of the box. Remote $ref to external URLs is intentionally disabled — fetching external schemas would leak your validation activity to third parties and break the privacy model. To validate against a multi-file schema, inline the referenced definitions into a single document using $defs, or run validation in your own CI with Ajv where remote refs are appropriate.
**Q: What does additionalProperties: false do?**
A: additionalProperties: false rejects any key that isn't declared in properties. It's the single most useful keyword for tightening contracts — without it, schemas are open by default and silently accept misspelled or malicious fields. Always set additionalProperties: false on input contracts (request bodies, config files, queue messages). Leave it true (or omit it) only when the schema is a partial description of a larger document.
**Q: How do I validate JSON against a schema in Node.js or Python?**
A: Node: install Ajv (npm i ajv ajv-formats), call new Ajv().compile(schema), then validate(data). Python: install jsonschema (pip install jsonschema), call jsonschema.validate(data, schema). For TypeScript, generate types from the schema using json-schema-to-typescript so compile-time and runtime stay in sync. Our JSON Schema validation guide has copy-paste recipes for Node, Python, and browser.
**Q: What's the difference between oneOf, anyOf, and allOf?**
A: allOf — must match every subschema (intersection, used for composition). anyOf — must match at least one (union, fast-fail). oneOf — must match exactly one (discriminated union, slower but stricter). Use oneOf for discriminated unions like webhook events tagged by type; use anyOf for permissive unions; use allOf to extend a base schema with extra constraints. oneOf is the slowest because it tests every branch — prefer anyOf when exactly-one isn't required.
**Q: Does it support OpenAPI schemas?**
A: OpenAPI 3.1 uses Draft 2020-12 natively, so any OpenAPI 3.1 schema component pastes in directly. OpenAPI 3.0 uses a Draft 4 subset that's mostly compatible — you may hit edge cases around nullable: true (3.0 syntax) which Draft 2020-12 expresses as type: ["string", "null"]. For full OpenAPI document validation (paths, operations, security), use a dedicated OpenAPI linter like Spectral; this tool focuses on the schema portion.
**Q: Why does the validator say my JSON Schema is itself invalid?**
A: JSON Schema is a JSON document that must be valid JSON before it can be a valid schema. Common causes: trailing comma in a properties object, single quotes instead of double, $schema set to a non-existent draft URL, or required listed as a string instead of an array. Format the schema in JSON Formatter first to surface syntax issues, then paste it back here for semantic validation.
**Q: Does the tool send my JSON or schema to a server?**
A: No. All parsing and validation runs locally in your browser. Your JSON, your schema, and the validation results never leave your machine — no upload, no localStorage of inputs, no analytics on what you paste. Safe for proprietary API contracts, internal config files, and sensitive payloads. Only your draft selection persists in localStorage so it survives a refresh; clear browser data to wipe it.
**Q: Can I validate JSON Lines (NDJSON) or multiple documents?**
A: This tool validates one document per run. For JSON Lines, validate each line individually or use Ajv in Node with a schema and a stream parser like JSONStream. For batch validation of large datasets, prefer the command-line — ajv-cli or check-jsonschema (Python) handle thousands of files per second with a single schema compile.
---
### JSON to CSV Converter
URL: https://go-tools.org/tools/json-to-csv
Convert JSON to CSV in your browser. RFC 4180, Excel-EU, TSV, Pipe presets. Flatten nested or stringify. 100% private, no upload.
#### What is CSV and Why Convert from JSON?
CSV (Comma-Separated Values) is the oldest and most widely supported tabular data format in computing — every spreadsheet app, every database, every analytics tool, and most programming languages have first-class CSV support. JSON, by contrast, is the universal format for API responses, configuration, and structured data exchange. Converting between them is one of the most common chores in data engineering: you receive JSON from an API or a NoSQL database, and you need a CSV to load into Excel for analysis, into a Postgres table via COPY, or into a BigQuery / Snowflake warehouse. This tool is built for that conversion path and handles four scenarios that most online converters botch.
This tool has four important differentiators compared to typical online converters:
**1. RFC 4180 State-Machine Parser.** CSV looks simple but the quoting rules are subtle: a field wrapped in double quotes can contain commas, embedded newlines, and escaped double quotes (doubled, like ""). Naive split-by-comma parsers break on real-world data — addresses with commas, multiline text fields, and quoted values containing quotes. This tool implements a proper state-machine parser following RFC 4180 (the IETF spec for CSV), correctly handling quoted fields, embedded delimiters, embedded line endings, and escaped quotes in every direction. The output is round-trippable through Python's csv module, PostgreSQL COPY, AWS S3 SELECT, and any compliant parser.
**2. Flatten One-Way / Stringify Reversible.** Nested JSON is fundamentally incompatible with CSV's flat tabular shape, and most converters silently corrupt data when they hit a nested object or array. This tool gives you an explicit choice: Flatten mode emits dotted keys (customer.address.city) and indexed keys (items.0.sku) for the cleanest spreadsheet layout — readable in Excel but lossy for round-trips. Stringify mode keeps arrays and objects as JSON inside a single cell — uglier but fully round-trippable: CSV → JSON → CSV produces identical data when paired with Infer types on the reverse. Choose based on your goal: analysis in Excel (Flatten) or pipeline round-trips (Stringify).
**3. Big-Integer Detection.** JavaScript's Number type uses IEEE 754 double precision and silently rounds integers above 2^53 - 1 (9007199254740991). This bites real-world JSON: Twitter snowflake IDs, Discord IDs, MongoDB Long fields, and Kubernetes resourceVersion are all 64-bit integers that exceed the safe range. Most browser-based JSON tools silently produce wrong numbers without warning. This tool detects big-integer values during parsing, shows a warning banner listing affected fields, and preserves the original digits as strings in the CSV output so Excel and Google Sheets won't truncate them to scientific notation.
**4. 100% Browser-Based Privacy.** Your JSON data — which often contains user PII, internal database exports, API keys embedded in payloads, and production secrets — never leaves your browser. No data is sent to any server, no logging, no analytics that capture input. You can verify this in your browser's Network tab. This is the only safe way to handle sensitive data in an online tool. See the reverse direction by clicking Swap or use our companion JSON to YAML Converter when YAML is your target. Need to validate JSON before converting? Try our JSON Formatter.
CSV's strengths are universality and simplicity: every tool reads it, parsers are tiny, and the file format is human-readable in any text editor. Its weaknesses are the lack of type information (everything is a string until you tell the parser otherwise), no native nested-structure support, and locale-specific quirks (Excel-EU semicolons, Windows CRLF vs Unix LF). JSON's strengths are exactly the opposite: precise types, native nesting, and a strict spec that parses identically everywhere. The right tool depends on the consumer: human reading a spreadsheet → CSV, machine consuming an API → JSON. This converter handles the bridge in both directions.
```
// Input JSON
[
{ "id": 1, "name": "Alice", "role": "admin" },
{ "id": 2, "name": "Bob", "role": "editor" }
]
// Output CSV (RFC 4180 preset: comma + CRLF + no BOM)
id,name,role
1,Alice,admin
2,Bob,editor
// Same input with Stringify mode + nested data
[
{ "id": 1, "tags": ["a", "b"] }
]
// Becomes
id,tags
1,"[""a"",""b""]"
```
#### FAQ
**Q: What does this tool do?**
A: It converts JSON to CSV directly in your browser, with bidirectional support: click Swap direction to convert CSV back to JSON in the same panel. Paste JSON in the input area and the tool produces CSV output instantly — no upload, no signup, nothing leaves your machine. The output respects your chosen preset (RFC 4180, Excel, TSV, or Pipe) so you can paste straight into Excel, Google Sheets, a database COPY command, or any data pipeline. The tool handles flat arrays of objects, nested structures (via Flatten or Stringify mode), NDJSON line-delimited input, and big-integer values that would otherwise lose precision in spreadsheet apps.
**Q: Is my data uploaded anywhere?**
A: No. All conversion runs 100% client-side in your browser using JavaScript. Your JSON data is never transmitted, never stored on any server, never logged, and never analyzed. This makes the tool safe for API responses containing PII, internal database exports, MongoDB dumps, and any sensitive data. You can verify this in your browser's Network tab — pasting JSON triggers zero network requests. The tool uses no cookies for input data and no third-party analytics that would capture what you paste.
**Q: What's the difference between Flatten and Stringify mode?**
A: Flatten mode emits dotted keys for nested objects and indexed keys for nested arrays (customer.address.city, items.0.sku) so each leaf value lives in its own column. This is the most readable layout for analysis in Excel or BigQuery, but it is lossy for round-trips because the dotted-key structure cannot be perfectly reconstructed. Stringify mode keeps arrays and objects as JSON inside a single cell ({"name":"Alice","city":"Seattle"}) — uglier in a spreadsheet, but fully round-trippable: CSV → JSON → CSV produces identical data. Choose Flatten for analysis, Stringify for round-trip safety. Pick before you convert; switching mid-session re-runs the conversion on the current input.
**Q: How does it handle big integers like Twitter IDs or Snowflake keys?**
A: Big integers (above 2^53 - 1, or 9007199254740991) are detected during JSON parsing and a warning banner appears below the output. The tool preserves the original digits as strings in the CSV so Excel and Google Sheets won't truncate them to scientific notation. This matters because JavaScript's IEEE 754 double-precision float silently rounds integers above 2^53 — for example, 9007199254740993 becomes 9007199254740992. To preserve precision when generating the JSON upstream, store these IDs as strings ("id": "9007199254740993"). The tool will keep them as strings in the CSV without any precision loss.
**Q: Why is Excel showing my CSV in one column?**
A: European Excel locales (Germany, France, Spain, Italy, etc.) expect a semicolon delimiter because the comma is reserved for decimal separators. When you open a comma-delimited CSV in Excel-EU, every row collapses into column A. Use the Excel preset on this tool — it switches the delimiter to ;, the line ending to CRLF, and adds a UTF-8 BOM so Excel correctly detects encoding and column boundaries. If you are sharing CSVs across regions, the safer option is TSV (Tab delimiter) which Excel handles consistently in every locale.
**Q: Does this support NDJSON or JSON Lines?**
A: Yes. NDJSON (.ndjson) and JSONL (.jsonl) are line-delimited formats where each line is one valid JSON value. Paste the file contents directly into the input area — the tool auto-detects the format by looking for multiple top-level JSON values separated by newlines, and treats each line as a row in the output CSV. This is the natural shape for streaming logs, API event exports, and many data lake pipelines. NDJSON does not require a wrapping array, so you do not need to manually merge lines into one JSON document.
**Q: What is RFC 4180?**
A: RFC 4180 is the IETF specification that codified the de facto CSV format in 2005. It defines the rules for delimiters (typically comma), line endings (CRLF), the optional header row, and most importantly the quoting rules: fields containing the delimiter, double quote, CR, or LF must be wrapped in double quotes, and embedded double quotes are escaped by doubling them (""). The RFC 4180 preset on this tool produces output strictly compliant with the spec: comma delimiter, CRLF line endings, no BOM, double-quote auto-escaping. This is the safest choice for interoperability with parsers in Python (csv module), PostgreSQL COPY, AWS S3 SELECT, and most data pipelines.
**Q: Why are some cells wrapped in quotes and others not?**
A: The default Quote mode is Auto, which follows RFC 4180: a cell is wrapped in double quotes only when it contains the delimiter, a double quote, a carriage return, or a newline. This produces the cleanest, most human-readable CSV — values like Alice or 42 stay unquoted, while values like Smith, Jr. or Line 1\nLine 2 get wrapped. Switch to Always quote mode to wrap every cell, even simple ones — useful when downstream tools have buggy CSV parsers that misinterpret unquoted values, or when your team's pipeline expects every field to be quoted for consistency.
**Q: Can I round-trip CSV → JSON → CSV without data loss?**
A: Yes, when the input is flat (no nested objects or arrays). For nested data, you must use Stringify mode — it keeps arrays and objects as JSON inside a single cell, which round-trips losslessly back to the original structure when you reverse with Swap direction and Infer types. Flatten mode is one-way: it emits dotted keys (customer.address.city) that cannot be perfectly reconstructed because the parser cannot distinguish a dotted key from a nested path. The tool detects nested structures and shows a Schema notes warning when round-trip safety is at risk so you can switch modes before exporting.
**Q: How do I get a TSV file?**
A: Click the TSV preset chip. This switches the delimiter to Tab, the line ending to LF, and disables the BOM — the standard format for tab-separated values used by Unix tools (cut, awk), data warehouses (BigQuery, Snowflake), and most Excel locales without ambiguity. TSV is generally safer than comma-CSV for cross-locale sharing because Tab is unlikely to appear inside text fields, eliminating most quoting edge cases. Save the output with a .tsv or .tab extension and most tools will recognize it automatically.
**Q: What happens with very large input?**
A: Above 100,000 characters or 2,000 rows, live conversion automatically switches to manual mode: a Convert button appears in an info banner and conversion only runs when you click it. This prevents the browser's main thread from blocking on every keystroke during heavy serialization. For output above 5 MB or 50,000 rows, the tool truncates the on-screen preview to the first 500 rows and shows a Showing the first 500 of N rows banner — but the Download button still produces the full file with every row included. Hard upper limit is 10 MB of input; above that the tool shows an error and asks you to reduce the input.
**Q: What encodings are supported?**
A: Input and output are both UTF-8. UTF-8 covers every modern character set including emoji, CJK ideographs, Arabic, Hebrew, and combining marks. The only encoding nuance is the optional UTF-8 BOM (Byte Order Mark): Excel on Windows traditionally needs the BOM to detect UTF-8 correctly, otherwise it falls back to the system locale and mangles non-ASCII characters. Toggle BOM on (or use the Excel preset, which enables BOM by default) when you plan to open the CSV in Excel. Leave BOM off for everything else — most modern parsers (PostgreSQL, Pandas, jq, Python csv) will choke or include the BOM as a stray character at the start of the first cell.
---
### JSON to .env Converter
URL: https://go-tools.org/tools/json-to-env
Paste a JSON object, get a .env file instantly. Generate dotenv from config locally — your keys and secrets never leave your browser. 100% private, no upload.
#### What is a .env File and Why Generate One from JSON?
A .env file (dotenv file) is a plain-text list of KEY=VALUE pairs that holds environment configuration and secrets outside your source code. It is the de facto standard for Node.js, Vite, Next.js, Python, Ruby and Docker Compose — the dotenv library loads the file and injects each pair into the process environment. Because it commonly stores database passwords, API keys and access tokens, a .env file is treated as sensitive and kept out of version control.
Generating a .env file from JSON is the reverse of the common parse-config task: you already have configuration as a JSON object — from an API response, a config export, a secrets-manager dump, or a script that builds settings programmatically — and you need a .env file to drop into a project or hand to a container. This converter walks the top-level keys of your JSON object and writes one correctly quoted KEY=VALUE line per property.
This tool is built around a few deliberate decisions:
**1. Round-trip-safe quoting.** Numbers and booleans are written bare, null becomes an empty value, and any string that contains a space, newline, # or quote is automatically double-quoted and escaped. The result parses back cleanly through dotenv and through the companion .env to JSON Converter, so a value never changes meaning on the round trip.
**2. Honest handling of nesting.** A .env file is flat by definition. Rather than silently dropping nested data, the tool serializes each nested object or array to a compact JSON string and warns you which keys were flattened, so you can decide whether .env is really the right target.
**3. Optional key normalization.** Keys are kept verbatim by default to avoid losing information. Turn on Normalize keys to convert camelCase or kebab-case into the UPPER_SNAKE_CASE convention environment variables use, with a warning for any key that still cannot form a valid name.
**4. 100% browser-based privacy.** The JSON you paste — usually the very credentials you are about to write into a .env — never leaves the browser. No upload, no server round-trip, no logging; verify zero network requests in the DevTools Network tab.
Before converting, you can validate or pretty-print the JSON with the JSON Formatter, or unescape a JSON string with JSON Escape. If your configuration is better expressed with structure, JSON to YAML preserves nesting that a flat .env cannot.
```
// Generate .env lines from a JSON object in Node.js
const config = {
DATABASE_URL: 'postgres://user:pass@localhost:5432/mydb',
PORT: 8080,
DEBUG: true,
NOTE: 'value with spaces',
};
const needsQuotes = (s) => /[\s#"'\n]/.test(s);
const env = Object.entries(config)
.map(([key, value]) => {
if (typeof value === 'string') {
return needsQuotes(value)
? `${key}=${JSON.stringify(value)}`
: `${key}=${value}`;
}
return `${key}=${value ?? ''}`; // null -> empty value
})
.join('\n');
console.log(env);
// DATABASE_URL=postgres://user:pass@localhost:5432/mydb
// PORT=8080
// DEBUG=true
// NOTE="value with spaces"
```
#### FAQ
**Q: How do I convert JSON to a .env file online?**
A: Paste a JSON object into the input field above. The tool generates a .env file instantly in your browser — no button click needed. Each top-level property becomes a KEY=VALUE line. You can optionally normalize keys to UPPER_SNAKE_CASE or add an export prefix from the Options panel, then click Copy to grab the result or Download to save it as a .env file. Everything runs locally, so your secrets never leave your device.
**Q: What kind of JSON does this accept?**
A: The input must be a JSON object (a set of key/value pairs at the top level), because a .env file is fundamentally a flat list of variables. A top-level array or a bare scalar like a string or number cannot map to environment variables, so the tool reports an error asking for an object. Invalid JSON also produces an error with best-effort line and column numbers so you can locate the problem quickly.
**Q: How are strings, numbers, booleans and null written?**
A: Numbers and booleans are written without quotes (PORT=8080, DEBUG=true). A null value becomes an empty assignment (KEY=), which dotenv loads as an empty string. Plain strings are written as-is, but a string containing spaces, a newline, a #, or a quote character is automatically wrapped in double quotes and escaped so it parses back correctly. This means the output round-trips cleanly through the dotenv parser and through our companion .env to JSON Converter.
**Q: What happens to nested objects and arrays?**
A: .env files cannot represent nesting — every variable is a flat string. When a value is a nested object or array, the tool serializes it to a compact JSON string with JSON.stringify, wraps it in double quotes, and escapes it. A non-blocking warning lists exactly which keys were flattened this way, so you always know the structure was collapsed. If your data is deeply nested, a format like JSON to YAML preserves the hierarchy far better than .env can.
**Q: What does the Normalize keys option do?**
A: By default the original JSON keys are kept exactly as written, so no data is lost — and in that mode any key that is not already a valid environment variable name (most shells and loaders only accept names matching [A-Za-z_][A-Za-z0-9_]*) is flagged with a warning so you can rename it. With Normalize keys enabled, keys are converted to UPPER_SNAKE_CASE — the conventional style for environment variables (databaseUrl becomes DATABASE_URL, enable-signup becomes ENABLE_SIGNUP) — which resolves most invalid names automatically.
**Q: Is my JSON data sent to a server?**
A: No. All conversion happens entirely in your browser with JavaScript. The JSON you paste — which often holds API keys, database credentials and tokens you are about to write into a .env file — is never transmitted, never stored on any server, and never logged. You can confirm this by opening your browser's Network tab and watching that pasting triggers zero requests. That is what makes it safe to generate a real production .env, not just a sample.
---
### JSON to Python Class Converter
URL: https://go-tools.org/tools/json-to-python
Paste JSON, get Python classes instantly — dataclass, Pydantic v2, or TypedDict. Correct Optional typing, camelCase aliases, nested classes. 100% in your browser, free.
#### What is JSON to Python conversion?
JSON to Python conversion turns a JSON sample into ready-to-use Python classes — a standard-library dataclass, a Pydantic v2 model, or a TypedDict — so you never hand-write field definitions for an API response or config file. This Python class generator infers correct types (int, float, str, bool, Optional), turns nested objects into named classes, and adds Pydantic aliases for camelCase keys, all 100% in your browser.
#### FAQ
**Q: How do I convert JSON to a Python class?**
A: Paste your JSON into the input box. The converter parses it instantly in your browser and generates Python on the right. Pick dataclass, Pydantic v2, or TypedDict with the toggle, then click Copy — no upload, no account, no waiting.
**Q: What is the difference between dataclass, Pydantic, and TypedDict output?**
A: dataclass gives you a standard-library @dataclass with no dependencies — great for plain data holders. Pydantic v2 emits BaseModel classes that validate and coerce data at runtime, ideal for parsing untrusted API responses. TypedDict describes the shape of a plain dict for static type checkers (mypy, Pyright) with zero runtime cost. Switch modes to compare the same JSON in each.
**Q: How do I generate a Pydantic model from JSON?**
A: Choose the Pydantic v2 tab. Fields are converted to snake_case with Field(alias="originalKey") so the model still reads camelCase JSON, and model_config = ConfigDict(populate_by_name=True) lets you construct it by field name too. Parse a payload with Root.model_validate(data) — Pydantic validates types and raises a clear error on bad input.
**Q: How does the dataclass output handle camelCase keys?**
A: A dataclass has no built-in alias, so to keep Root(**data) working, dataclass mode keeps the original key as the field name when it is a valid Python identifier (publicRepos stays publicRepos). If you want idiomatic snake_case with aliases, use the Pydantic v2 mode instead, which maps snake_case fields back to the exact JSON key.
**Q: How are optional and null fields typed?**
A: When a key appears in some array items but not others, its type is wrapped in Optional. A field that is only ever null becomes Optional[Any], because JSON null alone carries no type. Paste a representative sample with a filled-in value to get a more specific type than Any.
**Q: What Python type does each JSON value map to?**
A: Strings map to str, booleans to bool, whole numbers to int, and any number with a decimal point or exponent to float. Because Python integers are arbitrary precision, even huge IDs stay int — there is no 64-bit overflow. Empty or mixed-type arrays become List[Any], and objects become nested classes.
**Q: Does it handle nested objects and arrays of objects?**
A: Yes. Each nested object becomes its own named class, and identical shapes are deduplicated into a single class reused by every field. Arrays of objects are merged key by key so you get one element class, with keys missing from some items marked Optional. Child classes are always emitted before the classes that use them.
**Q: How are Python keywords and non-identifier keys handled?**
A: A JSON key that is a Python keyword (class, from, import) gets a trailing underscore (class_). Keys with hyphens, spaces, or a leading digit are sanitized to valid identifiers in dataclass and Pydantic modes. In TypedDict mode, any dict containing a non-identifier key is emitted with the functional TypedDict('Name', {...}) syntax so the exact key like "first-name" is preserved.
**Q: How do I use the generated dataclass to parse JSON?**
A: For a flat object, json.loads then Root(**data) works directly. For nested structures, dataclass does not recurse automatically — either build the child objects yourself, use a library like dacite or pydantic.dataclasses, or switch this tool to Pydantic v2 mode, where Root.model_validate(json.loads(text)) parses the whole tree in one call.
**Q: Is my JSON data private and safe?**
A: Yes. Conversion runs 100% in your browser with JavaScript. Your JSON — including tokens, IDs, or customer data — never leaves the page and is never sent to a server.
**Q: Is the tool free? Do I need an account?**
A: It is completely free with no sign-up, no limits, and no ads cluttering the workspace. It works offline once the page has loaded.
---
### JSON to Rust Struct Converter
URL: https://go-tools.org/tools/json-to-rust
Paste JSON, get idiomatic Rust serde structs instantly, 100% in your browser. Correct i64/u64/f64 typing, Option for nulls, #[serde(rename)] for camelCase. Free.
#### What is JSON to Rust conversion?
JSON to Rust conversion turns a JSON sample into ready-to-compile Rust structs with serde's #[derive(Serialize, Deserialize)] macros, so you never hand-write deserialization boilerplate for API responses or config files. This fast Rust struct generator infers correct number types, marks absent fields as Option, and adds #[serde(rename)] for non-snake_case keys — all 100% in your browser.
#### FAQ
**Q: How do I convert JSON to a Rust struct?**
A: Paste your JSON into the input box. The converter parses it instantly in your browser and generates Rust structs with serde derives on the right. Click Copy to grab the result — no upload, no account, no waiting.
**Q: Does it generate serde derives? Do I need serde and serde_json?**
A: Yes — output uses #[derive(Debug, Clone, Serialize, Deserialize)] by default. Add serde with the derive feature to your Cargo.toml. You only need serde_json as a dependency if the output contains serde_json::Value, which appears for empty or mixed arrays and null-only fields. Turn off the serde toggle to emit plain structs.
**Q: How do I use the generated struct to parse JSON?**
A: Add serde_json to your Cargo.toml, then deserialize in one line: let root: Root = serde_json::from_str(json)?;. The generated Deserialize derive does the rest — use serde_json::from_slice for a byte slice or from_reader for a file or HTTP body, and serde_json::to_string to serialize back.
**Q: How are optional and null fields handled?**
A: When a key appears in some array items but not others, it becomes an Option field. A field that is only ever null becomes an optional serde_json::Value. serde treats Option as optional automatically, so no #[serde(default)] attribute is added or required.
**Q: How does it handle camelCase keys and Rust keywords?**
A: Field names are converted to idiomatic snake_case, and a #[serde(rename)] attribute maps them back to the exact JSON key. Reserved keywords like type or match are emitted as type_ or match_ with a rename, which is more robust than raw identifiers because it also covers self, crate, and super.
**Q: Can it use #[serde(rename_all)] instead of per-field renames?**
A: The tool emits a per-field #[serde(rename)] because it always works — even when one payload mixes camelCase, snake_case, and irregular keys. If every field in a struct shares one convention, delete those attributes and put a single #[serde(rename_all = "camelCase")] on the struct instead; both deserialize identically.
**Q: What Rust number type does it use?**
A: Integers map to i64, or u64 when a value exceeds i64::MAX, and fall back to f64 beyond u64 — so large IDs still round-trip. Any number written with a decimal point or exponent (like 1.0 or 2e3) maps to f64, because serde would reject a float into an integer field.
**Q: How are dates and timestamps typed?**
A: JSON has no date type, so ISO strings like 2011-01-25 or RFC 3339 timestamps come out as String. For real date handling, change the field to a chrono type — DateTime in the Utc time zone, or NaiveDate — and enable chrono's serde feature. serde then parses RFC 3339 automatically.
**Q: How do I handle objects with dynamic or unknown keys?**
A: When keys vary — for example a map of IDs to values — replace the generated struct with a HashMap keyed by String. To keep a typed struct but still capture extra fields, add a #[serde(flatten)] field that is a HashMap. For fully dynamic values, serde_json::Value is the catch-all type.
**Q: Is my JSON data private and safe?**
A: Yes. Conversion runs 100% in your browser with JavaScript. Your JSON — including tokens, IDs, or customer data — never leaves the page and is never sent to a server.
**Q: Can I generate plain Rust structs without serde?**
A: Yes. Turn off the serde toggle to drop the use serde line, the Serialize and Deserialize derives, and all #[serde(rename)] attributes — leaving clean structs. You can also toggle Debug and Clone derives and pub visibility.
**Q: Is the tool free? Do I need an account?**
A: It is completely free with no sign-up, no limits, and no ads cluttering the workspace.
---
### JSON to TOML Converter
URL: https://go-tools.org/tools/json-to-toml
Paste JSON, get TOML instantly in your browser. Safe null handling, top-level table checks, Cargo.toml & pyproject.toml-ready output. 100% private, no upload.
#### What is TOML and Why Convert from JSON?
TOML (Tom's Obvious, Minimal Language) is a configuration file format built to be unambiguous and easy for humans to read and edit. It is the standard config format for the Rust ecosystem (Cargo.toml), modern Python packaging (pyproject.toml), and tools like Hugo, Netlify, Poetry, and Foundry. JSON is the universal machine format that tools and APIs produce. Converting JSON to TOML is common when you have structured data as JSON but need a human-editable TOML config as the destination — generating a Cargo.toml or pyproject.toml, or turning an application's JSON settings into a readable config file.
TOML is more structured than JSON, and this tool turns that strictness into guidance rather than cryptic failures:
**1. Top-level table enforcement.** Every TOML document is a table at the root — a bare array or scalar is not valid TOML. Instead of emitting broken output for { top-level array } input, this tool detects it and tells you exactly how to wrap your data under a key, so you always get valid TOML or a clear explanation.
**2. Safe, transparent null handling.** JSON has null; TOML does not. Most converters either crash or silently discard data. This tool is explicit: object keys with null values are dropped and the removed keys are listed in a warning, and a null inside an array — which has no valid TOML representation — produces a precise, path-pointing error. You are never surprised by missing data.
**3. Idiomatic TOML output.** Nested objects become [tables], deeply nested objects become dotted tables ([tool.ruff]), and arrays of objects become arrays of tables ([[section]]) — the shape real Cargo.toml and pyproject.toml files use. The conversion is powered by the zero-dependency, TOML 1.0.0-compliant smol-toml library.
**4. 100% browser-based privacy.** Your JSON — which may contain credentials, tokens, or internal service details — never leaves your browser. No upload, no server, no logging. Confirm it in your browser's Network tab.
Need the reverse? Use the TOML to JSON Converter. Working with other config formats? Try the JSON to YAML Converter and YAML to JSON Converter, or clean up your JSON input first with the JSON Formatter. Each format has its niche: JSON for machine interchange, TOML for human-edited application and tooling config, and YAML for deeply nested infrastructure manifests. This converter lets you move from JSON to TOML without writing any code.
```
// Convert JSON to TOML in Node.js using the smol-toml library
import { stringify } from 'smol-toml';
const data = JSON.parse(`{
"package": { "name": "my-app", "version": "1.0.0" },
"dependencies": { "serde": { "version": "1.0" } }
}`);
// The top-level value must be an object; null values on objects are dropped.
const toml = stringify(data);
console.log(toml);
// [package]
// name = "my-app"
// version = "1.0.0"
//
// [dependencies.serde]
// version = "1.0"
```
#### FAQ
**Q: How do I convert JSON to TOML online?**
A: Paste your JSON into the input field above. The tool parses it and produces TOML instantly in your browser — no button click needed. Once the TOML appears in the output area, click Copy to grab it to your clipboard or Download to save it as a .toml file. Everything runs locally, so your JSON never leaves your device. Two things to know before you start: your JSON's top level must be an object (not an array), and null values have no TOML equivalent — the tool explains both clearly if they come up.
**Q: What is TOML and why convert JSON to it?**
A: TOML (Tom's Obvious, Minimal Language) is a configuration format designed to be easy for humans to read and write, with unambiguous semantics. It is the config format for Rust's Cargo, Python's pyproject.toml, Hugo, Netlify, Poetry, and more. You convert JSON to TOML when a tool or API gives you JSON but the destination expects TOML — for example, generating a Cargo.toml or pyproject.toml from structured data, or turning an application's JSON settings into a human-editable TOML config file.
**Q: Why must the top level of my JSON be an object?**
A: TOML documents are always a table (a set of key-value pairs) at the root — the specification does not allow a bare array, string, or number at the top level. So a JSON array like [1, 2, 3] or a lone value like 42 cannot be converted directly. The fix is to wrap it under a key: { "items": [1, 2, 3] } converts cleanly to items = [1, 2, 3]. This tool detects a non-object top level and tells you exactly how to wrap it, instead of producing broken output.
**Q: What happens to null values when converting JSON to TOML?**
A: TOML has no null type, so null cannot be represented. This tool handles it safely and transparently in two ways. When a null appears as an object value, TOML simply omits that key — and the tool shows a warning listing exactly which keys were dropped, so you are never surprised by silent data loss. When a null appears inside an array, there is no valid TOML output at all (an array cannot hold a gap), so the tool reports an error pointing at the exact path of the offending null. Either way, you know precisely what happened and where.
**Q: How are nested objects and arrays converted to TOML?**
A: A nested JSON object becomes a TOML table: { "owner": { "name": "Tom" } } becomes [owner] with name = "Tom". Deeply nested objects become dotted tables like [tool.ruff]. An array of objects becomes an array of tables written with double brackets ([[servers]]), which is the idiomatic TOML way to express repeated sections. Arrays of scalars stay inline as arrays (ports = [8001, 8002]). The output follows the TOML 1.0.0 specification.
**Q: What happens to floating-point numbers like 1.0?**
A: TOML distinguishes integers from floats, and a float whose fractional part is zero (like 1.0) is written as the integer 1. So { "version": 1.0 } becomes version = 1. The tool shows a small warning when this coercion happens, because it changes the value's type on a round-trip. If you need the value to stay a float, that distinction cannot be preserved through TOML for whole numbers — consider whether an integer is actually what you want.
**Q: Is my JSON data sent to any server?**
A: No. All parsing and conversion happen entirely in your browser using JavaScript. Your JSON is never uploaded, never stored, and never logged. This makes the tool safe for configuration that contains API keys, database credentials, or internal service details. You can verify this by opening your browser's Network tab — pasting JSON triggers zero network requests.
**Q: Can I convert TOML back to JSON?**
A: Yes. Use the companion TOML to JSON Converter for the reverse direction, or click the Swap direction button at the top of this tool to flip the input and output in place. TOML to JSON has fewer constraints — it accepts any valid TOML — so round-tripping JSON → TOML → JSON is reliable as long as your JSON had no nulls or top-level array to begin with.
**Q: How do I convert JSON to TOML on the command line?**
A: A popular option is the Go tool 'yj' (yj -jt reads JSON and writes TOML). In Python you can use the third-party 'tomli-w' package: import json, tomli_w; tomli_w.dump(json.load(open('config.json')), open('config.toml','wb')). In Node.js: import { stringify } from 'smol-toml'; const toml = stringify(JSON.parse(text)) — the same library this tool uses. For a quick one-off without installing anything, this browser tool is the fastest path.
**Q: How do I convert JSON to TOML in Python, Rust, or Node.js?**
A: In Python: import json, tomli_w; tomli_w.dump(json.load(open('config.json')), open('config.toml','wb')). In Rust: use serde_json and toml — let value: serde_json::Value = serde_json::from_str(&text)?; let toml = toml::to_string_pretty(&value)?. In Node.js: import { stringify } from 'smol-toml'; const toml = stringify(JSON.parse(text)) — this is exactly the approach used by this tool. Remember that the top-level value must be an object in all of these.
**Q: Does the converter preserve key order?**
A: Keys within a table are preserved in their original order, but TOML structure requires that all plain key-value pairs of a table come before any child table headers. So top-level scalars are emitted first, then tables and arrays of tables — the converter reorders only where the TOML grammar demands it. The data is identical; only the textual ordering of table sections shifts to produce valid TOML.
**Q: Is there a file size limit for JSON input?**
A: There is no hard limit, but inputs over 200KB switch from live conversion to manual mode: a Convert button appears and conversion runs only when you click it, keeping the browser responsive. Typical configuration payloads convert in well under 50 milliseconds.
---
### JSON to TypeScript Converter
URL: https://go-tools.org/tools/json-to-typescript
Paste JSON, get TypeScript interfaces instantly. 100% in your browser — data never leaves the page. interface or type, nested objects, arrays, optional fields. Free, no sign-up.
#### What is JSON to TypeScript conversion?
JSON to TypeScript conversion reads a JSON value and generates matching TypeScript interface or type definitions — eliminating hand-written boilerplate for API responses and config files. Paste a payload and get production-ready types in seconds, fully typed for nested objects, arrays, and optional fields.
#### FAQ
**Q: How do I convert JSON to a TypeScript interface?**
A: Paste your JSON into the input box. The converter reads it instantly in your browser and generates a TypeScript interface on the right. Click Copy to grab the result — no upload, no account.
**Q: Should I use `type` or `interface` for JSON data?**
A: Both work. `interface` is conventional for object shapes and gives slightly better editor errors; `type` is handy for unions and intersections. Use the Output toggle to switch between them and keep whichever your codebase prefers.
**Q: How are nested objects and arrays handled?**
A: Nested objects become separate, named interfaces (e.g. an `address` field yields an `Address` interface). Arrays of objects are merged into one element interface; primitive arrays become typed arrays like `string[]`.
**Q: How are optional and null fields handled?**
A: When a key is present in some array items but not others, it is marked optional. Choose `?:` (optional) or `| null` (explicit nullable) with the Optional fields toggle. Literal null values are typed as `null`.
**Q: How do I generate TypeScript types from JSON automatically in VSCode?**
A: You can install an extension, but you don't have to. This tool runs entirely in your browser — paste, copy, done — with no plugin to install, configure, or keep updated.
**Q: Is my JSON data private and safe?**
A: Yes. Conversion happens 100% in your browser using JavaScript. Your JSON — including any tokens, IDs, or customer data — never leaves the page and is never sent to a server.
**Q: Is the tool free? Do I need an account?**
A: It is completely free with no sign-up, no limits, and no ads cluttering the workspace.
**Q: Can it detect dates or enums?**
A: Date strings are kept as `string` (safer than guessing). String values are typed as `string` rather than literal unions, so the output stays stable as your data changes.
---
### JSON to XML Converter
URL: https://go-tools.org/tools/json-to-xml
Paste JSON, get XML instantly. Converts objects, arrays, and @_ attributes in-browser — nothing uploaded. Free, private, no signup required.
#### What is JSON-to-XML Conversion and How Does It Work?
JSON (JavaScript Object Notation) and XML (Extensible Markup Language) are both structured data formats, but they have fundamentally different models: JSON is a tree of objects, arrays, strings, numbers, booleans, and null values with no concept of attributes or document root constraints; XML is a tree of elements that may carry attributes and text content, and the document must have exactly one root element. Converting from JSON to XML requires a set of conventions to bridge this mismatch.
This tool uses the most widely adopted convention — the same one used by fast-xml-parser (Node.js), xmltodict (Python), and JAXB (Java) — applied in reverse:
**1. Root element normalization.** The single most important difference between JSON and XML is the root constraint. JSON has no root concept; XML requires exactly one. The converter handles four cases automatically. A single-key object uses that key as the XML root: { "config": {...} } → ... . A multi-key object wraps in : { "a": 1, "b": 2 } → 12 . A top-level array wraps as - ...
value .
**2. @_ prefix → XML attributes.** JSON keys prefixed with @_ become XML attributes on the enclosing element. { "element": { "@_id": "42", "@_class": "primary" } } produces 29.99 . Elements with only text content (no @_ keys) convert to plain text elements without this indirection.
**4. Arrays → repeated same-named sibling elements.** XML allows multiple child elements with the same name; JSON uses arrays for ordered lists. A JSON array under a key produces repeated child elements that reuse the key name: { "items": ["a", "b"] } produces a b (the two elements are siblings under the parent). When the entire JSON input is a top-level array, a wrapper is added and each element becomes an - child —
- is a fixed fallback name used only in that case.
**5. Symmetric with XML-to-JSON.** The @_ and #text conventions used here are exactly the same conventions used by the companion XML to JSON Converter. This means a JSON → XML → JSON round-trip preserves attributes, text content, and element structure — as long as the input JSON follows the @_/#text conventions.
**When to convert JSON to XML?** The most common scenarios are: (1) sending data to a legacy SOAP or XML-based web service that requires an XML request body; (2) generating XML configuration files (Spring, Maven, Ant, Android resources) from JSON data; (3) producing sitemap.xml or RSS feed XML from JSON content data; (4) interoperating with enterprise systems (ERP, CRM, EDI) that consume XML; (5) generating SVG or other XML-based graphics formats programmatically from JSON data. For formatting and validating the resulting XML, use the XML Formatter.
```
// Convert JSON to XML in Node.js using fast-xml-parser
import { XMLBuilder } from 'fast-xml-parser';
const data = {
catalog: {
product: {
'@_id': 'P01',
'@_category': 'electronics',
name: 'Wireless Headphones',
price: {
'@_currency': 'USD',
'#text': '79.99'
}
}
}
};
const builder = new XMLBuilder({
attributeNamePrefix: '@_', // @_ keys become XML attributes
textNodeName: '#text', // #text key becomes element text content
ignoreAttributes: false, // process @_ attribute keys
format: true, // pretty-print with indentation
indentBy: ' ', // 2-space indent
});
const xml = builder.build(data);
console.log(xml);
//
//
// Wireless Headphones
// 79.99
//
//
```
#### FAQ
**Q: Is my JSON data sent to a server when I use this tool?**
A: No. All conversion happens entirely inside your browser using JavaScript. Your JSON is never transmitted over the network, never stored on any server, and never logged or analyzed. This makes the tool safe to use with JSON payloads containing API credentials, database configuration, internal service data, or any other sensitive content. You can verify this by opening your browser's Network tab — you will see zero requests triggered by pasting or converting JSON.
**Q: How does the tool decide what the XML root element is?**
A: XML requires exactly one root element; JSON has no such constraint. The converter applies these rules: (1) A single-key object uses that key as the root element name — { "user": { ... } } becomes ... . (2) A multi-key object (two or more keys at the top level) is wrapped in a element so all keys become children of a single root. (3) A top-level array is wrapped as - ...
- child. (4) A primitive value (string, number, boolean, null) at the top level becomes
value . These rules guarantee the output is always well-formed XML with exactly one root.
**Q: Why does a multi-key JSON object get wrapped in ?**
A: XML is a document format with a strict single-root requirement — a valid XML document must have exactly one top-level element. JSON objects can have any number of top-level keys, so when your JSON has multiple top-level keys (such as { "status": 200, "data": {...}, "meta": {...} }), there is no single key to use as the root. Wrapping in is the safest and most predictable convention. If you want a different root element name, reshape your JSON to a single-key object before converting — e.g. { "response": { "status": 200, "data": {...} } }.
**Q: How does a top-level JSON array convert to XML?**
A: A top-level array is wrapped as - ...
- ...
- child — "item" is a fixed literal name used only for top-level arrays. This is distinct from arrays nested under an object key: if you write { "products": [...] }, each array element becomes a
child (reusing the key name), not . If you want custom tag names for a top-level array, wrap it in a named object first: { "products": [...] } gives you repeated elements.
**Q: How do I convert JSON keys to XML attributes?**
A: Prefix the key with @_ and the converter will emit it as an XML attribute instead of a child element. For example, { "tag": { "@_id": "42", "@_lang": "en", "#text": "Hello" } } produces Hello . The @_-prefix convention is the same one used by fast-xml-parser (Node.js) and xmltodict (Python), making the output round-trip consistently with those libraries. This is also the convention used by the companion XML to JSON Converter.
**Q: What is the #text key used for?**
A: When an element needs both XML attributes and text content, you cannot simply map the text to a child element — it must be the element's own text node. The #text key in your JSON becomes that text content. Example: { "price": { "@_currency": "USD", "#text": "29.99" } } produces 29.99 . If an object has only a #text key and no @_ keys, it still produces a plain text element: { "note": { "#text": "hello" } } becomes hello .
**Q: Does indentation affect the XML structure?**
A: No. Indentation is purely cosmetic — it changes how the XML is formatted for human readability but does not affect the element structure, attribute values, or text content. Choose 2 spaces for compact output or 4 spaces for more readable output. Both produce semantically identical XML. Most XML parsers treat whitespace-only text nodes between elements as ignorable whitespace, so indented and minified XML are equivalent for parsing purposes.
**Q: How does a JSON array nested inside an object convert to XML?**
A: A JSON array value under a key produces repeated same-named child elements, reusing the key name for every element. For example, { "items": [1, 2, 3] } produces three siblings — not - . Similarly, { "products": [{"name":"A"},{"name":"B"}] } produces two
elements, each containing a child. The key name is used as-is for every array element; no singularization occurs. The only place the literal name - appears is when the entire JSON input is a top-level array (see above), where
- is a fixed fallback wrapper name.
**Q: How do I convert XML back to JSON?**
A: Use the companion XML to JSON Converter. It applies the same @_ and #text conventions in reverse: XML attributes become @_-prefixed JSON keys, element text content paired with attributes becomes a #text key, and repeated same-named sibling elements become a JSON array. The two tools are symmetric for round-trip use cases.
**Q: Can I validate or format the XML output?**
A: Yes — paste the XML output into the XML Formatter to validate well-formedness, adjust indentation, or minify. The XML Formatter is the right tool for inspecting and polishing the XML once this converter has produced it.
**Q: Is there a file size limit for JSON input?**
A: There is no hard limit, but inputs larger than 200KB automatically switch from live conversion to manual mode. In manual mode a Convert button appears and conversion runs only when you click it — this keeps the browser responsive during heavy serialization. For very large JSON files (multi-megabyte), consider command-line tools for better performance: node -e "const {XMLBuilder}=require('fast-xml-parser');console.log(new XMLBuilder({attributeNamePrefix:'@_'}).build(JSON.parse(require('fs').readFileSync('in.json','utf8'))))" or an equivalent Python script with xmltodict.
**Q: What JSON types are supported?**
A: All six JSON types are supported. Objects become XML elements with child elements. Arrays become repeated same-named sibling elements. Strings, numbers, booleans, and null become element text content. Booleans and null are serialized as their literal string representations: true, false, and empty content for null. No type coercion is applied — numbers are written to XML text content exactly as they appear in the JSON, preserving decimals and precision.
---
### JSON to YAML Converter
URL: https://go-tools.org/tools/json-to-yaml
Paste JSON, get YAML instantly. Live conversion in your browser. K8s/Compose-ready, 2/4-space indent, smart quoting. 100% private, no upload.
#### What is YAML and Why Convert from JSON?
YAML (YAML Ain't Markup Language) is a human-readable data serialization format designed for configuration files, infrastructure-as-code, and anywhere a human writes data that a machine will read. Its indentation-based syntax requires no braces or brackets, making it far more legible than JSON for complex nested structures. Kubernetes, Helm, Ansible, Docker Compose, GitHub Actions, CircleCI, and virtually every cloud-native tool uses YAML as its primary configuration format. Converting JSON to YAML is therefore one of the most common tasks in DevOps and backend development — you receive a resource definition from an API in JSON, and you need a YAML manifest to commit to version control.
This tool has four important differentiators compared to typical online converters:
**1. Norway Problem — Auto-Safe Quoting.** The single biggest footgun in JSON-to-YAML conversion is the YAML Norway Problem. In YAML 1.1 (which millions of production parsers still use, including older Kubernetes, PyYAML, Ansible, and Ruby's Psych), the bare strings yes, no, on, off, y, and n are parsed as boolean true/false values. This famously bit the ISO country code for Norway ("NO" → false) and has caused real production outages in Kubernetes configs. YAML 1.2 fixed this, but your parsers may not be on 1.2. This tool's default Auto quote mode uses the eemeli/yaml library with the YAML 1.1 schema, so it automatically wraps any Norway-problem string in quotes, guaranteeing safe round-trips through both YAML 1.1 and 1.2 parsers. Learn more in our companion article at The YAML Norway Problem and JSON-YAML Differences.
**2. Key Order Preservation.** Unlike some converters that sort keys alphabetically, this tool preserves the original key insertion order from your JSON — matching the behavior of JSON.parse() in all modern JavaScript engines. This matters for Kubernetes manifests (where apiVersion and kind are expected first by convention), OpenAPI specs (where info appears before paths), and any config where field ordering is meaningful for readability or diffs.
**3. Big-Number Precision Caveat.** JSON numbers larger than 2^53 - 1 (9007199254740991) cannot be represented exactly in JavaScript's IEEE 754 double-precision float. When JSON.parse() reads a large integer like a Kubernetes resourceVersion field (which is a 64-bit integer on the server), it silently truncates it. This is a fundamental browser JavaScript limitation that affects every browser-based JSON tool, including this one. The safe workaround is to ensure large integers are stored as strings in your JSON before converting. This tool documents this behavior honestly in the Number Precision Loss common error below.
**4. 100% Browser-Based Privacy.** Your JSON data — which often contains API keys, database credentials, internal service configurations, and production secrets — never leaves your browser. No data is sent to any server. You can verify this in your browser's Network tab. This is the only safe way to handle sensitive configuration data in an online tool. See our companion tool for the reverse direction at YAML to JSON Converter, and our JSON Formatter if you need to validate and pretty-print JSON before converting.
YAML's human-readable nature comes with a tradeoff: it has more parsing edge cases than JSON. Beyond the Norway Problem, YAML has octal number quirks (0777 is parsed as 511 in YAML 1.1), multiline string syntax (| for literal, > for folded), anchor and alias references (&anchor and *alias), and multiple document support (--- separator). JSON has none of these complexities — it is a strict, minimal format with only six data types. For machine-to-machine data exchange, JSON is almost always the better choice. For human-edited configuration files where readability and comments matter, YAML wins. This converter gives you the best of both: use JSON programmatically, convert to YAML for your infrastructure. Need to compare two JSON documents and find what changed? Try our JSON Diff. If your destination is a spreadsheet rather than YAML, use JSON to CSV (or the reverse CSV to JSON) instead.
```
// Convert JSON to YAML in Node.js using the eemeli/yaml library
import { Document } from 'yaml';
const data = JSON.parse('{"apiVersion":"apps/v1","kind":"Deployment"}');
// version: '1.1' ensures Norway-problem strings (yes/no/on/off/y/n)
// are automatically quoted in the output for YAML 1.1 parser safety
const doc = new Document(data, { version: '1.1' });
const yamlString = doc.toString({
indent: 2,
lineWidth: 0, // disable line wrapping
defaultStringType: 'PLAIN', // Auto mode: only quote when needed
});
console.log(yamlString);
// apiVersion: apps/v1
// kind: Deployment
```
#### FAQ
**Q: How do I convert JSON to YAML online?**
A: Paste your JSON into the input field above. The tool converts it to YAML instantly in your browser — no button click needed. You can adjust indentation (2 or 4 spaces), quoting style (Auto, Double, or Single), and output style (Block or Flow) from the Options panel. Once the YAML appears in the output area, click Copy to grab it to your clipboard or Download to save it as a .yaml file. Everything runs locally — your data never leaves your device.
**Q: What is the YAML Norway Problem and how does this tool handle it?**
A: The YAML Norway Problem refers to a quirk in YAML 1.1 specification where bare strings like "no", "yes", "on", "off", "y", and "n" are parsed as boolean values (false/true) instead of strings. This caused a famous real-world issue where the ISO country code for Norway ("NO") was misread as the boolean false in Ansible playbooks and Kubernetes configs. In YAML 1.2, this was fixed — bare strings are always strings. However, millions of production parsers (older Kubernetes versions, PyYAML, Ansible, Ruby's Psych) still use YAML 1.1. This tool's Auto quote mode (the default) automatically wraps any Norway-problem strings in quotes so they round-trip safely through both YAML 1.1 and 1.2 parsers. When Norway-problem strings are detected in your input, a warning banner lists exactly which values were auto-quoted.
**Q: Why does the Norway Problem matter for Kubernetes and DevOps?**
A: Kubernetes YAML manifests, Helm chart values, Ansible playbooks, and GitHub Actions workflows are all parsed by tools that historically used YAML 1.1. If you have a config key with the value "no" (for example, a country code, an enabled flag in string form, or a custom boolean-like field), a YAML 1.1 parser will silently convert it to the boolean false. This can cause service misconfigurations that are extremely difficult to debug because the YAML appears correct when viewed as text but behaves differently when parsed. Always use Auto quote mode when converting JSON for use in Kubernetes or any DevOps toolchain to guarantee safe round-trips.
**Q: Should I use 2-space or 4-space indentation for YAML?**
A: Use 2-space indentation for Kubernetes manifests, Helm values, Docker Compose files, and GitHub Actions workflows — these tools are designed around 2-space YAML and it is the community convention. Use 4-space indentation for Ansible playbooks (which follow a 4-space convention) and when your team or organization has a style guide mandating it. YAML forbids tabs entirely — all indentation must be spaces. This tool defaults to 2 spaces, which is the correct choice for the vast majority of cloud-native use cases.
**Q: How do I use this tool to create a Kubernetes manifest?**
A: If you have a Kubernetes resource definition in JSON (from kubectl get deployment my-app -o json, an API response, or a Terraform resource block), paste it into the input field. Select 2 spaces indentation (the default) and Auto quotes (the default, which handles the Norway Problem). The YAML output is immediately ready for kubectl apply -f. You can also click Download to save the file with a .yaml extension and pipe it directly into kubectl apply -f -. The K8s Deployment example above shows a complete deployment manifest you can load and modify.
**Q: How do I convert a Docker Compose JSON to YAML?**
A: Paste your Docker Compose JSON into the input field. Use 2-space indentation (Docker Compose convention) and Block style. The output YAML is compatible with docker compose up, docker compose config, and Docker Stack. A common scenario is exporting a running stack's configuration with docker inspect and then converting it back to a compose.yaml file. The Docker Compose example above includes service definitions with ports, environment variables, volumes, and depends_on.
**Q: Can JSON numbers larger than 2^53 lose precision when converting to YAML?**
A: Yes. This is a fundamental JavaScript limitation: the IEEE 754 double-precision float used by JavaScript's Number type can only represent integers exactly up to 2^53 - 1 (9007199254740991). Any integer beyond that — such as Kubernetes resourceVersion fields (which are int64 on the server) — will be silently rounded when parsed by JSON.parse(). For example, the value 9007199254740993 becomes 9007199254740992 in JavaScript, and this truncated number will appear in your YAML output. This affects all browser-based JSON tools, not just this one. The safe workaround is to store large integers as strings in your JSON ("resourceVersion": "9007199254740993") — they will appear as YAML strings without any precision loss.
**Q: Does the converter preserve the original key order from my JSON?**
A: Yes. The eemeli/yaml library used by this tool preserves insertion order, which matches the behavior of JSON.parse() in all modern JavaScript engines (V8, SpiderMonkey, JavaScriptCore). Keys appear in the YAML output in the same order they appeared in the JSON input. This is important for Kubernetes manifests and OpenAPI specs where field ordering is often meaningful for readability and diffs.
**Q: When should I use JSON versus YAML?**
A: Use JSON when: you are building APIs and web services (JSON is the universal interchange format), when machine parsing speed matters, when you need strict type safety, or when the consumer is a JavaScript/TypeScript application. Use YAML when: writing configuration files intended for human editing (Kubernetes manifests, CI/CD pipelines, Ansible playbooks, Helm values), when you want comments in your config, or when readability is more important than strictness. A helpful rule: if a machine writes it or reads it first, use JSON; if a human writes it and a machine reads it, use YAML.
**Q: How can I convert JSON to YAML on the command line?**
A: The most popular approach is combining yq and jq. Install yq (Mike Farah's version, not the Python one): brew install yq on macOS or wget https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 -O /usr/local/bin/yq for Linux. Then run: cat input.json | yq -P to pretty-print as YAML. Alternatively: yq -o yaml input.json or cat input.json | python3 -c "import sys, json, yaml; yaml.dump(json.load(sys.stdin), sys.stdout, default_flow_style=False)". For Kubernetes specifically: kubectl get deployment my-app -o yaml converts directly from the cluster API.
**Q: How do I convert JSON to YAML in Python, Node.js, or Go?**
A: In Python: import json, yaml; yaml.dump(json.load(open('input.json')), open('output.yaml', 'w'), default_flow_style=False) using PyYAML, or ruamel.yaml for round-trip fidelity. In Node.js: import { Document } from 'yaml'; const doc = new Document(JSON.parse(input), { version: '1.1' }); const result = doc.toString({ indent: 2, lineWidth: 0 }) — this is the same library and approach used by this tool. In Go: import gopkg.in/yaml.v3; json.Unmarshal(jsonBytes, &data); yaml.Marshal(data) — note that Go YAML v3 uses YAML 1.1 by default, so Norway-problem strings will be auto-quoted.
**Q: Is my JSON data sent to any server when I use this tool?**
A: No. All conversion happens entirely in your browser using JavaScript. Your JSON data is never transmitted over the network, never stored on any server, and never logged or analyzed. This makes the tool safe to use with API keys, database credentials, internal configuration files, production Kubernetes manifests, and any other sensitive data. The tool uses no cookies for your input data and no third-party analytics that would capture your paste. You can verify this by opening your browser's Network tab — you will see zero requests triggered by pasting JSON.
**Q: Is there a file size limit for JSON input?**
A: There is no hard file size limit, but large inputs (over 200KB) automatically switch from live conversion to manual mode. In manual mode, a Convert button appears and conversion runs only when you click it — this prevents the browser's main thread from blocking for 200-500ms on every keystroke. For very large JSON files (multi-megabyte), consider using command-line tools like yq or jq for better performance. The tool efficiently handles typical real-world payloads like full Kubernetes namespace dumps, large OpenAPI specs, and multi-service Docker Compose files.
---
### JSON to Zod Schema Converter
URL: https://go-tools.org/tools/json-to-zod
Paste JSON, get a ready-to-use Zod schema instantly, 100% in your browser. Correct z.number().int(), .optional() and .nullable(), plus a z.infer type. Free.
#### What is a Zod schema?
A Zod schema is a TypeScript-first description of a value's shape that validates data at runtime and infers a static type at compile time. Generating one from a JSON sample means you never hand-write validation boilerplate for API responses, forms, or config files. This Zod schema generator infers correct types, marks absent keys as .optional(), null values as .nullable(), and hands you a z.infer type — all 100% in your browser.
#### FAQ
**Q: How do I convert JSON to a Zod schema?**
A: Paste your JSON into the box on the left. The converter parses it instantly in your browser and generates a Zod schema on the right, together with a z.infer type alias. Click Copy to grab it — no upload, no account, no waiting.
**Q: What is the difference between JSON to Zod and JSON Schema to Zod?**
A: This tool takes a sample JSON value — an API response or object — and infers a Zod schema from its shape. JSON Schema to Zod is a different task: it converts an existing JSON Schema document into Zod. If you have raw data, use this tool. If you already have a JSON Schema file, convert that instead.
**Q: How do I get a TypeScript type from the schema?**
A: Every result includes a z.infer type alias, so you get a fully typed Root without writing it by hand. Keep the schema as the single source of truth and let TypeScript derive the type, so the two never drift apart. You can toggle the z.infer line off in Options if you only want the schema.
**Q: How are optional and null fields handled?**
A: When a key appears in some array items but not others, its field is marked .optional(). A field that is null in some samples and typed in others becomes .nullable(). A field that is only ever null becomes z.null(). Zod treats optional and nullable independently, so the schema matches how your data actually varies.
**Q: What number type does it generate?**
A: Whole numbers map to z.number().int(); any value written with a decimal point or exponent maps to z.number(). If a field mixes integers and decimals across samples, it unifies to z.number() so validation never rejects a legitimate value.
**Q: Does the output work with Zod 3 and Zod 4?**
A: Yes. The generated code uses the common, stable subset — z.object, z.string, z.number, z.array, z.union, .int, .optional, .nullable and z.infer — that behaves the same in Zod 3 and Zod 4. Just make sure the zod package is installed in your project.
**Q: How do I validate data with the generated schema?**
A: Import the schema and call RootSchema.parse(data) to throw on invalid input, or RootSchema.safeParse(data) to get a typed success or error result without throwing. This is ideal at trust boundaries such as API responses, form input, and environment config.
**Q: How are arrays and mixed types handled?**
A: An array of one type becomes z.array of that type. An array of objects merges key by key into a single element schema. An array that mixes primitive types becomes a z.union, and anything more ambiguous falls back to z.unknown so you can refine it from a richer sample.
**Q: Is my JSON data private and safe?**
A: Yes. Conversion runs 100% in your browser with JavaScript. Your JSON — including tokens, IDs, or customer data — never leaves the page and is never sent to a server.
**Q: Is the tool free? Do I need an account?**
A: It is completely free with no sign-up, no limits, and no ads cluttering the workspace.
---
### JSON Unescape
URL: https://go-tools.org/tools/json-unescape
Unescape a JSON string back to readable text in your browser. Decodes \n, \t, \", \\, and \uXXXX, with or without surrounding quotes. 100% private, no upload.
#### What is JSON Unescaping and When Do You Need It?
JSON unescaping is the reverse of JSON escaping: it takes a string full of escape sequences — \n, \t, \", \\, \uXXXX — and turns each one back into the character it represents, recovering the original text. Where escaping makes a string safe to store inside a JSON document, unescaping makes a stored string readable again.
The need shows up constantly in debugging and data work. You copy a field out of a structured log and it is full of \n and \" that hide the real message — unescaping reveals the actual multi-line text. An API stored a request body as a string (JSON-in-JSON), and you need to read the inner object — unescaping turns {\"a\":1} back into {"a":1}. A legacy system emitted ASCII-safe output where every accent became \uXXXX — unescaping restores café and résumé. In each case the data is technically intact but unreadable until decoded.
This tool is built for that decode path with three advantages. First, it is lenient about the surrounding quotes: paste a full literal or just the escaped body, and it does the right thing — because escaped strings are usually copied out of context. Second, it decodes \uXXXX correctly, combining surrogate pairs into proper astral characters like emoji, identical to a compliant JSON parser, so anything escaped by a serializer round-trips perfectly. Third, it runs 100% in your browser, so the log fields and payloads you decode — which often contain PII or secrets — never reach a server. To re-escape afterward, use our JSON Escape tool; to validate the decoded JSON, see the JSON Formatter.
```
// Escaped input (copied from a log, quotes optional)
User said: \"it works!\"\nSession ended.
// Unescaped output — readable again
User said: "it works!"
Session ended.
// \uXXXX and surrogate pairs decode too
caf\u00e9 \ud83d\ude00 -> café 😀
// JSON-in-JSON
{\"a\":1} -> {"a":1}
```
#### FAQ
**Q: What does this JSON unescape tool do?**
A: It reverses JSON escaping: it takes a JSON-escaped string and decodes the escape sequences back into the characters they represent, entirely in your browser. \n becomes a real newline, \t a tab, \" a double quote, \\ a single backslash, \/ a forward slash, and \uXXXX the corresponding Unicode character (including surrogate pairs for emoji and astral scripts). The result is the original, human-readable text. You can paste the string with or without its surrounding double quotes — the tool detects and handles both. Everything runs client-side, so escaped payloads containing sensitive data never leave your machine.
**Q: Do I need to include the surrounding double quotes?**
A: No — the tool accepts both forms. If you paste a complete JSON string literal like "hello\nworld" (with the outer quotes), it is parsed directly. If you paste just the escaped body hello\nworld (no outer quotes), the tool wraps it for you before decoding. This is convenient because escaped strings are often copied out of the middle of a larger document, where the surrounding quotes were left behind. Either way you get the same decoded text.
**Q: Is my data uploaded anywhere?**
A: No. All decoding runs entirely in your browser using JavaScript — the escaped string you paste is never transmitted, stored, logged, or analyzed on any server. This makes the tool safe for decoding log fields, webhook payloads, and config values that may contain PII or secrets. You can confirm it in your browser's Network tab: pasting triggers zero network requests. No cookies capture your input and no third-party analytics read what you paste.
**Q: Why do I get an 'invalid escape sequence' error?**
A: The error means the input is not a valid JSON-escaped string, so it cannot be decoded unambiguously. The most common cause is a lone backslash followed by a character JSON does not recognize as an escape — for example \q or \x41 (JSON has no \x hex escape; it uses \u). Another cause is an unbalanced or stray double quote inside an unquoted input, which breaks the automatic wrapping. Check that every backslash starts a valid escape (\n \t \r \b \f \" \\ \/ \uXXXX) and that quotes are properly paired.
**Q: How do I read a JSON object that was stored as a string (JSON-in-JSON)?**
A: Paste the escaped string — for example {\"a\":1} — and the tool decodes it back to the real JSON {"a":1}, which you can then read or copy into a parser. This double-decoding is exactly what you need when a webhook envelope, message-queue record, or audit log stored a request body as an escaped string field. After unescaping, paste the result into our JSON Formatter to pretty-print and validate it. To go the other direction and escape JSON for embedding, use the JSON Escape tool.
**Q: Does it correctly decode \uXXXX and emoji?**
A: Yes. Each \uXXXX is decoded to its UTF-16 code unit, and consecutive high/low surrogate escapes are combined into the correct astral character — so \ud83d\ude00 becomes 😀 and \u00e9 becomes é. This is the same decoding any compliant JSON parser performs, which means a string escaped by our JSON Escape tool (or any serializer) round-trips back to the exact original here, byte for byte. If the escape you are holding has a different shape — a `U+` code point, an HTML entity, or the bare `u4e2d` that is left over when a log pipeline swallows the backslash — our Unicode converter recognises those too and turns them back into readable text.
---
### Free JSONPath Tester — Evaluate Queries Online
URL: https://go-tools.org/tools/jsonpath-tester
Test JSONPath expressions against any JSON, 100% private in your browser — no upload, no signup, no eval. RFC 9535 standard engine plus Classic Goessner mode, with Values, Paths and Both result views.
#### What is a JSONPath tester?
A JSONPath tester is a tool that lets you write a JSONPath expression, paste a JSON document, and see exactly which nodes the expression selects — both the matched values and their precise locations — without writing code or running a script. For developers it shortens the loop from minutes to milliseconds: tweak the path, watch the result change, and ship the query with confidence.
JSONPath is a query language for JSON, the JSON analogue of XPath for XML. An expression is built from a small alphabet of selectors. $ is the root of the document. A dot or a bracket steps into a child: $.store or $['store']. The double dot .. is recursive descent — it searches every level of the tree. The wildcard * selects all elements or members. Brackets carry array indices ([0]), slices ([start:end:step]), unions ([a,b]), and filter expressions ([?(@.price < 10)], where @ is the element being tested). With those pieces you can pull a single field out of a deeply nested API response, assert on values in tests, drive data transforms in systems like Kubernetes, AWS Step Functions, and Azure Logic Apps, or extract structured data from irregular JSON — all without imperative traversal code. JSONPath is also famously inconsistent between implementations, which is exactly the problem a good tester surfaces before it reaches production.
This tester ships two engines. The default is an RFC 9535 engine: RFC 9535 is the IETF's February 2024 formal specification of JSONPath, the first time the language was precisely standardized after fifteen years of divergent implementations. It defines an exact grammar, the concept of normalized paths for results, and five standard functions — length(), count(), match(), search(), value(). Our RFC 9535 engine is a zero-dependency implementation that uses no eval, so it parses and interprets expressions with its own grammar instead of compiling them to JavaScript. The second engine is Classic (Goessner), the de facto 2007 dialect that most older online tools and libraries implement; switch to it to reproduce results from a tool like jsonpath.com or to run an expression you copied from legacy code. The two dialects agree on common paths but diverge in the edge cases — filter whitespace and quoting, union ordering, how missing members compare, and which functions exist — so being able to flip between them in one place is the fastest way to diagnose why an expression behaves differently than you expected.
What the tester surfaces beyond raw values: the result of a JSONPath query is a nodelist, and this tool can show it three ways. The Values view renders the matched nodes as a JSON array, exactly what you would consume in code. The Paths view renders each match's normalized path — a canonical, bracket-quoted location such as $['store']['book'][0]['title'] that uniquely identifies where in the document the value lives, no matter how the expression was written. Two expressions that select the same node produce the same normalized path, which makes the Paths view invaluable for debugging. The Both view shows values and paths side by side. A stats line reports how many nodes matched.
Security is a first-class concern here. Many online JSONPath evaluators run on a server, or embed a library that evaluates filter predicates with JavaScript eval — the design that produced remote-code-execution vulnerabilities tracked as CVE-2024-21534 and CVE-2025-1302 in widely used JSONPath packages. This tool uses no eval at all. The RFC 9535 engine has no eval path, and the Classic engine is built on a patched, pinned release of jsonpath-plus with eval explicitly disabled. That closes the RCE class of bugs and lets the tool run under a strict Content-Security-Policy that forbids unsafe-eval. Every evaluation is local: your JSON and your expression never leave the page, are never logged, and are never stored on disk — only your engine and view preferences persist to localStorage. That makes the tool safe for proprietary API payloads, redacted logs, internal config, and any data with a schema you would not paste into a server-backed service.
If JSON wrangling is your task, pair this with the other JSON tools on the site: format and pretty-print your input with the JSON Formatter, compare two documents with the JSON Diff, check a payload against a schema with the JSON Schema Validator, or turn a sample response into typed interfaces with JSON to TypeScript.
```
// The expression you build in this tester maps straight onto the
// RFC 9535 reference library used under the hood.
import { query, paths } from 'jsonpath-rfc9535';
const document = {
store: {
book: [
{ title: 'Sayings of the Century', author: 'Nigel Rees', price: 8.95 },
{ title: 'Sword of Honour', author: 'Evelyn Waugh', price: 12.99 },
{ title: 'Moby Dick', author: 'Herman Melville', price: 8.99 },
{ title: 'The Lord of the Rings', author: 'J. R. R. Tolkien', price: 22.99 }
]
}
};
// Values: query(document, path) returns the matched values directly.
const titles = query(document, '$.store.book[*].title');
// → ['Sayings of the Century', 'Sword of Honour', 'Moby Dick', 'The Lord of the Rings']
// Filter: books cheaper than 10.
const cheap = query(document, '$.store.book[?(@.price < 10)].title');
// → ['Sayings of the Century', 'Moby Dick']
// Normalized paths: paths(document, path) returns where each match lives.
const authorPaths = paths(document, '$..author');
// → ["$['store']['book'][0]['author']", "$['store']['book'][1]['author']", ...]
// RFC 9535 functions like length() are used INSIDE filters, not as a segment.
const longTitles = query(document, '$.store.book[?length(@.title) > 15]');
// → the two books whose title is longer than 15 characters
```
#### FAQ
**Q: Is my JSON or JSONPath expression sent to your server?**
A: No. Every evaluation runs in JavaScript inside your browser. Your JSON document and your JSONPath expression are not uploaded, not logged, not stored on disk, and not sent to any third party. Only your UI preferences — the active engine (RFC 9535 or Classic) and the result view (Values / Paths / Both) — are saved to localStorage so the page remembers them next visit; the JSON and the expression themselves are never persisted. You can verify by opening DevTools → Network: typing in either box fires zero requests. That makes this tool safe for proprietary API payloads, redacted log samples, internal config, and anything else you would not paste into a server-backed evaluator like jsonpath.com.
**Q: What is JSONPath and what is it used for?**
A: JSONPath is a query language for JSON, the same way XPath is a query language for XML. You write a path expression — for example $.store.book[*].author — and the evaluator returns every value in the document that the path selects. It is used to pull specific fields out of API responses, to assert on values in integration tests, to configure data transforms in tools like Jenkins, Kubernetes, AWS Step Functions, and Azure Logic Apps, and to extract data from large or irregular JSON without writing imperative traversal code. An expression is built from an axis of selectors: $ (the root), . or [] (child access), .. (recursive descent), * (wildcard), [start:end:step] (array slice), [a,b] (union), and [?()] (filter). This tester evaluates the expression live and shows both the matched values and their normalized paths.
**Q: What is the difference between RFC 9535 and the classic Goessner syntax?**
A: Classic JSONPath is the de facto syntax Stefan Goessner published in 2007. It became widely implemented but was never formally standardized, so subtle behaviors — how filters are written, how unions and the root function work, how absent values compare — diverged across libraries. RFC 9535, published by the IETF in February 2024, is the first formal specification of JSONPath. It nails down a precise grammar, defines normalized paths for results, and adds standard functions (length, count, match, search, value). The two are close but not identical: RFC 9535 is stricter about whitespace and quoting in filters, defines comparison semantics for missing members, and rejects some loose constructs the classic dialect tolerated. This tool defaults to the RFC 9535 engine (a zero-dependency, no-eval implementation) and lets you switch to a Classic (Goessner) engine for backward compatibility.
**Q: Why does the same expression return different results in the two engines, and how do I use an expression copied from jsonpath.com?**
A: Because RFC 9535 and the classic Goessner dialect have genuinely different rules in the edge cases — filter whitespace and quoting, union ordering, how missing members compare, and which functions exist. An expression written for one engine can match differently (or fail to parse) in the other. If you copied an expression from an older tool such as jsonpath.com, jsonpath-plus, or a Jayway-based service, switch the engine toggle at the top to Classic (Goessner): that mode runs a Goessner-compatible evaluator (built on jsonpath-plus, constructed with eval disabled) and will reproduce the behavior you saw in the source tool. If you are writing a new expression or targeting a system that advertises RFC 9535 compliance, keep the default RFC 9535 engine. The cheat sheet and built-in examples are written to evaluate identically in both engines so you have a known-good starting point.
**Q: How do filter expressions [?()] work?**
A: A filter selector keeps only the array elements (or object members) for which a predicate is true. Inside the filter, @ refers to the current element being tested. $.store.book[?(@.price < 10)] returns every book whose price member is less than 10. You can compare against literals (@.isbn, @.category == 'fiction'), combine conditions with && and ||, test for the existence of a member (@.isbn selects elements that have an isbn at all), and in RFC 9535 use the function extensions inside the predicate (?(length(@.tags) > 2)). Comparison operators are ==, !=, <, <=, >, >=. RFC 9535 is precise about types: comparing a missing member to a value is well-defined and does not throw. The classic dialect is looser about whitespace, so [?(@.price<10)] and [?(@.price < 10)] are both accepted there; RFC 9535 follows its grammar exactly.
**Q: What does recursive descent (..) do?**
A: The .. operator searches every level of the document, not just the immediate children. $..author collects every author member wherever it occurs — inside the top-level object, inside arrays, inside nested objects, at any depth. It is the fastest way to extract a field from a deeply nested or irregularly shaped structure when you do not want to (or cannot) spell out the full path. You can follow .. with any selector: $..book[*] finds every element of every book array anywhere in the tree, $..* enumerates every value in the document, and $..['price'] gathers all price members. Recursive descent can match a lot — switch to the Paths view to see exactly where each result came from via its normalized path.
**Q: What are the RFC 9535 functions length(), count(), match(), search(), and value()?**
A: RFC 9535 defines five standard function extensions, and the key rule is that they are only callable inside a filter expression [?...] — never as a standalone path segment. Writing $.store.book.length() is not valid RFC 9535 and the standard grammar rejects it (that segment-call form is a jsonpath-plus extension, not part of the spec). length() returns the length of a string, array, or object, so you use it to filter by size: $.store.book[?length(@.title) > 15] keeps books whose title is longer than 15 characters. count() returns the number of nodes a nodelist contains, again inside a filter: $.store.book[?(count(@.authors) > 1)]. match() tests whether a string matches a regular expression against the whole value, and search() tests for a match anywhere within the string — both take an I-Regexp pattern. value() converts a single-node nodelist to its value so it can be used in a comparison. These functions are part of the RFC 9535 standard, so they are available in the default engine; the Classic (Goessner) engine does not implement them. If a function-based expression fails, confirm you are calling it inside a filter and that the engine toggle is set to RFC 9535.
**Q: How do array slices [start:end:step] work?**
A: Slices use the same half-open convention as Python and JavaScript: [start:end] selects from index start up to but not including index end, so [0:2] returns the first two elements (indices 0 and 1). Omit a bound to run to the edge — [2:] from index 2 onward, [:3] for the first three. A negative index counts from the end: [-1:] selects the last element. The optional third field is a step — [::2] takes every other element, [::-1] reverses (in engines that support negative steps). The exclusive end bound is the single most common slice bug; the Paths view shows the exact index of every selected element so you can confirm the boundary at a glance.
**Q: What is a union selector and how do I select multiple keys at once?**
A: A union selector lists several names or indices inside one bracket and gathers all of them: $['title','author'] selects both members from an object, and $.store.book[0,2] selects the first and third elements of the book array. You can mix it with other selectors — $.store.book[*]['title','price'] pulls the title and price of every book. Unions are handy when you want a fixed projection of a few fields rather than a whole object or a wildcard. The Both view is the clearest way to read a union result because it pairs each selected value with its normalized path, so you can tell which name or index produced each entry.
**Q: Can I share a JSONPath query and its JSON via a link?**
A: Yes — and the link involves no server roundtrip. Click Copy link in the action bar: the tester encodes the JSON, the expression, the active engine, and the result view into the URL hash. Anyone who opens the link hydrates the page with the same state, locally on their own machine. Because the data lives in the hash fragment, it is never transmitted to the go-tools.org server — browsers do not send the fragment in HTTP requests — and it never appears in our access logs. The link length grows with the size of the JSON, so for large documents share just the expression and let the recipient paste their own data, or use the Upload button to load a file locally. This makes permalinks safe for collaborative debugging without exposing the payload to any backend.
**Q: Is there a maximum JSON size?**
A: Evaluation is bounded by your browser's memory rather than a hard cap, but the practical sweet spot is documents up to a few megabytes — comfortably larger than almost any single API response. Very large arrays with broad selectors (a $..* recursive wildcard over tens of thousands of nodes) will produce a large result set that takes longer to render; narrow the expression to keep the output readable. The Upload button reads a .json or .txt file entirely in the browser (it is never sent anywhere), and Format JSON re-indents the input so you can read the structure before querying it. For multi-megabyte data pipelines, validate your expression here against a representative slice, then run the same path in your application code or in a CLI tool like jq.
**Q: How is this different from jsonpath.com and is it safe — no eval?**
A: Four differences. (1) Privacy: jsonpath.com and most online evaluators run on a server or embed a library that evaluates filters with JavaScript eval; this tool runs entirely in your browser and uses no eval at all. The default RFC 9535 engine is a zero-dependency implementation with no eval path, and the Classic (Goessner) engine is built on jsonpath-plus pinned to a patched release with eval explicitly disabled — closing the remote-code-execution class of bugs tracked as CVE-2024-21534 and CVE-2025-1302. That also means the tool works under a strict Content-Security-Policy. (2) Standards: this is one of the few online testers offering a true RFC 9535 engine, not just the legacy Goessner dialect. (3) Dual-engine: you can switch between RFC 9535 and Classic to compare results or to run expressions copied from older tools, side by side. (4) Languages: the interface is available in 15 languages. If you only need quick legacy-syntax checks, jsonpath.com still works; for standards-compliant, private, no-eval evaluation, this is the safer choice.
**Q: What do the Values, Paths, and Both views show?**
A: The result of a JSONPath query is a nodelist — a set of nodes inside your document. The Values view renders those nodes as a JSON array of the matched values, exactly what you would consume in code. The Paths view renders the normalized path of each match instead — a canonical, bracket-quoted location like $['store']['book'][0]['title'] that uniquely identifies where in the document the value lives, regardless of how your expression was written. Normalized paths are an RFC 9535 concept and are invaluable for debugging: two different expressions that select the same node produce the same normalized path. The Both view shows the two side by side so you can match each value to its location at a glance. Your chosen view persists across sessions via localStorage.
**Q: Does this work offline, and what about a Content-Security-Policy?**
A: Yes on both counts. Because every evaluation runs in your browser with no network calls, the tool keeps working once the page has loaded even if you go offline. And because neither engine uses eval or the Function constructor to evaluate filter expressions, the tool runs under a strict Content-Security-Policy that forbids unsafe-eval — the policy that many security-conscious organizations enforce and that breaks eval-based JSONPath libraries. The RFC 9535 engine parses and interprets expressions with its own grammar rather than compiling them to JavaScript, and the Classic engine is configured with eval disabled. If you need to evaluate JSONPath inside a hardened internal environment, this tool is designed to run there without policy exceptions.
---
### JWT Decoder
URL: https://go-tools.org/tools/jwt-decoder
Decode JWT tokens online with our free JWT decoder. Instantly inspect header, payload, signature, expiration, algorithm, and claims. 100% browser-based — your token never leaves your device. No signup, no tracking.
#### What is a JWT?
A JSON Web Token, or JWT (pronounced 'jot'), is a compact, URL-safe token format for carrying claims between two parties. It is defined in RFC 7519 and is the dominant credential format used by OAuth 2.0 access tokens, OpenID Connect ID tokens, API keys in modern auth providers (Auth0, Okta, Clerk, Supabase, Firebase), and inter-service tokens in microservice architectures.
"JSON Web Token (JWT) is a compact claims representation format intended for space-constrained environments such as HTTP Authorization headers and URI query parameters." — RFC 7519, Section 1
A JWT is three Base64URL-encoded JSON objects joined by dots:
(note the plural). Fix: match tag names exactly, including case. (2) Unclosed tags — a tag that never has a corresponding close tag or self-closing slash. Fix: add the closing tag or change to becomes { "@_id": "42", "@_role": "admin" } inside the user object. This prefix is unambiguous: no valid XML element name starts with @, so there is no collision with child element names.
**2. Element text content with attributes → #text.** When an element has both attributes and text content — 29.99 — the text must share the same JSON object as the attributes. The convention is to store it under the key #text, producing { "@_currency": "USD", "#text": "29.99" }. Elements with only text content and no attributes convert to a plain string value.
**3. Repeated sibling elements → arrays.** XML allows multiple child elements with the same name; JSON objects cannot have duplicate keys. The solution is to collect same-named siblings into an array. One - child becomes a single object; two or more
- children become an array of objects. This is the most important behavioral detail to understand: the JSON shape changes based on how many siblings exist in the XML.
**4. No type coercion — all values stay strings.** XML has no native type system for text content. A value of "123" in XML is a string. Converting it to the JSON number 123 requires making an assumption about the author's intent — an assumption that is wrong for ZIP codes ("01234" → 1234), phone numbers, padded identifiers, and precision-sensitive decimal strings. This tool preserves all values as strings. Apply type coercion in your own code for the fields where you know the type.
**5. Lossy for comments, processing instructions, and namespaces.** XML supports features that JSON does not: comments (), processing instructions (), and namespace semantics. These are discarded or approximated during conversion. For lossless XML work — reformatting, minifying, validating — use the XML Formatter instead. For the reverse conversion — building XML from JSON — use the JSON to XML Converter.
**Why convert XML to JSON at all?** JSON is the native format of JavaScript and the default interchange format for REST APIs. If you receive XML from a legacy SOAP service, an RSS feed, a sitemap, or an enterprise system, converting it to JSON lets you work with the data using standard JavaScript object access, JSON path queries, and any JSON-aware database or API. The conversion is a one-way bridge: useful for consuming XML data in a modern stack, but not for preserving or round-tripping XML documents.
```
// Convert XML to JSON in Node.js using fast-xml-parser
import { XMLParser } from 'fast-xml-parser';
const xml = `
Wireless Headphones
79.99
`;
const parser = new XMLParser({
ignoreAttributes: false, // preserve attributes
attributeNamePrefix: '@_', // @_ prefix for attributes
textNodeName: '#text', // #text for mixed element content
parseAttributeValue: false, // no type coercion on attributes
parseTagValue: false, // no type coercion on element text
});
const result = parser.parse(xml);
console.log(JSON.stringify(result, null, 2));
// {
// "catalog": {
// "product": {
// "@_id": "P01",
// "name": "Wireless Headphones",
// "price": {
// "@_currency": "USD",
// "#text": "79.99"
// }
// }
// }
// }
```
#### FAQ
**Q: Is my XML data sent to a server when I use this tool?**
A: No. All conversion happens entirely inside your browser using JavaScript. Your XML is never transmitted over the network, never stored on any server, and never logged or analyzed. This makes the tool safe to use with XML payloads containing API credentials, internal service configuration, SOAP WS-Security tokens, healthcare HL7/FHIR data, or any other sensitive content. You can verify this by opening your browser's Network tab — you will see zero requests triggered by pasting or converting XML.
**Q: How do XML attributes map in the JSON output?**
A: XML attributes become JSON keys prefixed with @_. For example, produces a JSON object containing "@_id": "P01" and "@_category": "electronics" alongside any child element keys. When an element has both attributes and text content — such as 29.99 — the text content is stored under the special key "#text", so the result is { "@_currency": "USD", "#text": "29.99" }. This convention is consistent and predictable: @_ always means attribute, #text always means element text content.
**Q: Does the converter coerce numbers or booleans?**
A: No. All XML text content and attribute values become JSON strings, regardless of how they look. 42 becomes "count": "42", not 42. true becomes "enabled": "true", not true. This is intentional and important: it preserves leading zeros (phone numbers, account codes, ZIP codes like "01234"), numeric precision for values like "0.100", and string values that happen to look boolean. If you need numbers or booleans in your downstream JSON, apply type coercion in your own code after converting — where you control exactly which fields get coerced.
**Q: How are repeated (same-named sibling) elements handled?**
A: A single child element becomes a JSON object. Two or more child elements with the same tag name under the same parent become a JSON array. For example, - a
- a
- b
becomes "soap:Body" in the JSON). The semantic meaning of namespaces — that two prefixes might point to the same URI — is not interpreted. If precise namespace handling matters for your use case, parse the XML in a namespace-aware parser rather than converting to JSON.
**Q: Why does 0123 become "0123" and not 123?**
A: Because the converter performs no type coercion. The string "0123" and the number 123 are different values: "0123" has a leading zero that is meaningful in many contexts (account codes, postal codes, national identification numbers, padded identifiers). Silently dropping that leading zero would corrupt data. The safe default is to preserve all values as strings exactly as they appear in the XML. Apply numeric parsing selectively in your own code for the specific fields where you know the value is always a plain integer.
**Q: What is the difference between this tool and an XML formatter?**
A: The XML Formatter reformats XML — it changes indentation and whitespace but the output is still XML. This XML-to-JSON Converter changes the format entirely: the output is a JSON document that represents the XML structure using the @_ attribute convention. Use the formatter when you want to read, edit, validate, or minify XML. Use this converter when you need to work with the XML data in a JavaScript application, feed it into a REST API, or store it in a JSON document store.
**Q: Is there a file size limit?**
A: There is no hard limit, but inputs larger than 200KB automatically switch from live conversion to manual mode. In manual mode, a Convert button appears and conversion runs only when you click it — this keeps the browser responsive while parsing large XML documents. For very large XML files (multi-megabyte data exports), consider command-line tools for better performance: python3 -c "import sys, xmltodict, json; print(json.dumps(xmltodict.parse(sys.stdin.read()), indent=2))" or node -e with a dedicated XML-to-JSON library.
**Q: Does the converter handle CDATA sections?**
A: Yes. CDATA section content () is treated as element text content and appears as a plain string value in the JSON output. The CDATA delimiters themselves are stripped — only the content inside is preserved. For example, 
```
**Small JavaScript Files**
```html
```
## Base64 Variants
### Standard Base64 (RFC 4648)
- Uses `+` and `/` as the last two characters
- Uses `=` for padding
- Safe for most applications
### URL-Safe Base64 (RFC 4648 Section 5)
- Replaces `+` with `-`
- Replaces `/` with `_`
- May omit padding (`=`)
- Safe for URLs and filenames
### Comparison Example
```
Standard: "??>" → Pz8+
URL-Safe: "??>" → Pz8-
```
## Practical Code Examples
### JavaScript Implementation
```javascript
// Encoding
function encodeBase64(str) {
return btoa(unescape(encodeURIComponent(str)));
}
// Decoding
function decodeBase64(str) {
return decodeURIComponent(escape(atob(str)));
}
// Usage
const original = "Hello, World!";
const encoded = encodeBase64(original);
const decoded = decodeBase64(encoded);
console.log(`Original: ${original}`);
console.log(`Encoded: ${encoded}`);
console.log(`Decoded: ${decoded}`);
```
### Python Implementation
```python
import base64
# Encoding
def encode_base64(data):
if isinstance(data, str):
data = data.encode('utf-8')
return base64.b64encode(data).decode('ascii')
# Decoding
def decode_base64(encoded_data):
return base64.b64decode(encoded_data).decode('utf-8')
# Usage
original = "Hello, World!"
encoded = encode_base64(original)
decoded = decode_base64(encoded)
print(f"Original: {original}")
print(f"Encoded: {encoded}")
print(f"Decoded: {decoded}")
```
## Real-World Applications
### Web API Authentication
Many APIs use Base64 for basic authentication:
```javascript
const username = "user";
const password = "pass";
const credentials = btoa(`${username}:${password}`);
fetch('/api/data', {
headers: {
'Authorization': `Basic ${credentials}`
}
});
```
### JSON Web Tokens (JWT)
JWTs use Base64URL encoding for their header and payload:
```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0...
```
### Image Embedding
Embedding small images directly in HTML:
```html
```
## Performance Considerations
### Size Increase
Base64 encoding increases data size by approximately **33%**:
- 3 bytes of binary data → 4 bytes of Base64 text
- Overhead ratio: 4/3 = 1.33
### When to Use Base64
**Good for:**
- Small files (< 10KB)
- Reducing HTTP requests
- Embedding in CSS/HTML
- Text-based protocols
**Avoid for:**
- Large files
- Frequently changing content
- When binary transfer is available
- Performance-critical applications
### Caching Implications
- Base64 data URLs can't be cached separately
- Changes to embedded data require cache invalidation
- Consider external files for frequently updated content
## Best Practices
### 1. Choose the Right Variant
- Use standard Base64 for general purposes
- Use URL-safe Base64 for URLs and filenames
- Consider omitting padding when safe
### 2. Optimize for Performance
- Keep embedded data small (< 10KB)
- Use external files for large or frequently changing content
- Consider gzip compression for Base64 text
### 3. Security Considerations
- Base64 is encoding, **not encryption**
- Don't use Base64 to hide sensitive data
- Validate decoded data before use
### 4. Debugging Tips
- Use online tools for quick encoding/decoding
- Check for proper padding
- Verify character set compatibility
- When debugging config files that contain Base64 values, a [JSON5/JSONC-aware formatter](/blog/json5-jsonc-formatting-guide) can help you inspect them without stripping comments
## Try It Yourself
*Encode and decode Base64 instantly with our [Base64 Encoder/Decoder](/tools/base64-decode-encode) — supports UTF-8, URL-safe variants, and real-time conversion. 100% in your browser.*
## Frequently Asked Questions
### Does Base64 encoding provide any security?
No — Base64 is an encoding scheme, not encryption. Anyone can decode Base64 data without a key. It is designed for safe data transport, not confidentiality. Never use Base64 to "protect" sensitive information like passwords or API keys. For security, use proper encryption algorithms like AES-256 or TLS for data in transit.
### Why does Base64 increase data size by about 33%?
Base64 represents every 3 bytes of binary data as 4 ASCII characters. This 3-to-4 ratio means the output is always approximately 4/3 (133%) of the input size — a 33% increase. This overhead is the trade-off for being able to safely transmit binary data through text-only channels like email or JSON.
### What is the difference between standard Base64 and URL-safe Base64?
Standard Base64 uses `+` and `/` characters, which have special meanings in URLs. URL-safe Base64 (RFC 4648) replaces them with `-` and `_`, making the output safe for use in URLs, query parameters, and filenames without additional [percent-encoding](/tools/url-decoder-encoder). Most modern APIs prefer URL-safe Base64 for tokens and identifiers.
### When should I use Base64 Data URLs instead of regular image files?
Use Data URLs for small images under 2-4KB, like icons and simple logos, to eliminate an HTTP request. For larger images, regular files with proper caching are more efficient — Data URLs cannot be cached independently, increase HTML size by 33%, and must be re-downloaded with every page load.
### Can I use Base64 to encode non-ASCII text like Chinese or emoji?
Yes, but you must first convert the text to bytes using a character encoding like UTF-8, then Base64-encode those bytes. When decoding, reverse the process: Base64-decode to bytes, then interpret the bytes as UTF-8 text. Most modern libraries handle this automatically, but always specify UTF-8 explicitly to avoid encoding errors.
## Conclusion
Base64 encoding is a fundamental technology that bridges the gap between binary data and text-based systems. From its origins in email attachments to modern web applications, Base64 continues to be an essential tool for developers.
**Key takeaways:**
- Base64 converts binary data to safe ASCII text
- It's essential for email attachments and data URLs
- Choose the right variant for your use case
- Consider performance implications for large data
- Remember: it's encoding, not encryption
---
### Image to Base64 & Data URIs: When to Inline Images (2026)
URL: https://go-tools.org/blog/base64-images-data-uri-inline-guide
Should you convert an image to Base64? See when data URIs help, the 33% size cost, CSS/HTML inlining, caching tradeoffs, and when a normal image file wins.
When you convert an **image to Base64**, you get a **data URI**: a string like `data:image/png;base64,iVBORw0KGgo…` that you can paste straight into an HTML `src` or a CSS `url()`. The browser decodes it on the spot and shows the picture with no separate download. No file to host, no extra request.
So should you do it? Here is the short rule. Inline an image as Base64 when it is small (under about 2 KB), rarely changes, and you want to skip one HTTP request. Think tiny icons and logos. For everything else, keep it as a normal image file: large images, anything reused across pages, anything you want the browser to cache. The catch is that Base64 makes a file about 33% larger, and once that text is embedded in your HTML or CSS it can no longer be cached on its own.
If you want the exact numbers for a specific file, the [Image to Base64 converter](/tools/image-to-base64) does the encoding in your browser and shows the precise size increase, so you can decide with real data instead of a rule of thumb. This guide covers what that data URI actually is, the math behind the size tax, a decision matrix for when inlining pays off, and the cases where a plain file wins.
## What "image to Base64" actually produces: the data URI
Converting an image to Base64 does not give you a file. It gives you one long string that follows the data URI format defined in RFC 2397 (see [MDN's `data:` URL reference](https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Schemes/data) for the full spec). The string has three parts:
```
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
└──┬─┘ └───┬───┘ └─┬──┘ └─────────┬──────────┘
data: MIME type marker the encoded image bytes
```
The MIME type tells the browser what kind of image it is decoding. The common ones for images are `image/png`, `image/jpeg`, `image/gif`, `image/webp`, `image/svg+xml`, and `image/x-icon` for favicons. The `;base64,` marker says the payload that follows is Base64 rather than plain text. Everything after the comma is the image, re-expressed as printable ASCII.
That last part matters for privacy. The conversion runs entirely in your browser through the `FileReader` API's `readAsDataURL`, so nothing is uploaded to a server. You can drop a pre-launch screenshot or unreleased artwork into the tool and watch the Network tab stay empty. For the mechanics of how raw bytes become that ASCII string, [understanding Base64](/blog/understanding-base64) covers the encoding from the ground up, and the [complete Base64 guide](/blog/base64-complete-guide) extends the same data-URL idea to fonts, PDFs, and other file types.
### A real example: a 68-byte transparent PNG
Here is the smallest practical case, a 1×1 transparent PNG, 68 bytes on disk, written out as a complete data URI:
```
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==
```
Paste that into a browser address bar and you will see (well, not see, since it is transparent) a valid image render with zero network activity. Notice the trailing `==`: that is padding, which we will get to. This is also exactly what text Base64 looks like, just applied to image bytes instead of text. If you only need to encode or decode plain text strings, the [Base64 encode/decode](/tools/base64-decode-encode) tool handles that case.
## The 33% size tax (and why it compounds)
Base64 works in fixed groups: every 3 bytes of binary become 4 ASCII characters. Four-thirds is roughly 1.33, which is where the +33% figure comes from. Add a byte or two of padding plus the `data:image/png;base64,` prefix and the overhead is slightly higher for tiny files. A concrete example: a 9 KB PNG becomes about 12 KB of text.
Why exactly 3-to-4? Base64 uses a 64-character alphabet: `A`–`Z`, `a`–`z`, `0`–`9`, plus `+` and `/`. Sixty-four symbols is 6 bits of information per character, while binary bytes are 8 bits each. The lowest common multiple of 6 and 8 is 24 bits, which is 3 bytes or 4 Base64 characters, so the encoder works through the image 24 bits at a time. When the image length is not a clean multiple of 3, one or two `=` characters pad the final group. That math is fixed; no encoder setting shrinks the 33%.
That 33% is the visible cost. The hidden cost is that it compounds, and this is the part most "just inline it" advice skips:
- **The image is re-downloaded whenever the containing file changes.** An external `logo.png` is its own resource. Inline it into `styles.css`, and now any edit to that stylesheet, even a one-line color tweak, invalidates the cache for the image too. Visitors re-download the picture they already had.
- **It cannot be cached independently.** A normal image file is fetched once and reused across every page and every visit. An inlined data URI is part of the document, so it ships again on every page that embeds it and on every cache miss of that document.
- **CSS is render-blocking.** The browser will not paint until it has the CSS. Stuff a large data URI into a stylesheet and you have made a render-blocking resource bigger, delaying first paint for the whole page.
### Does gzip or brotli cancel the 33% out?
Partly, not fully. Base64 text is repetitive enough that gzip and brotli compress it well, clawing back a good chunk of the inflation over the wire. But two things remain true. First, the compressed Base64 is usually still a little larger than the compressed original binary, because you have handed the compressor a less efficient starting point. Second, and this is the part that bites, compression does nothing about caching or render-blocking. A smaller-over-the-wire data URI is still re-downloaded with its host file and still cannot be cached on its own.
So compressing the bytes is not the same as removing the cost of inlining them. If the distinction between minifying, gzipping, and brotli is fuzzy, the [code minification guide](/blog/code-minification-guide-css-js-html) lays out how those layers stack, and why squeezing the bytes never fixes the caching problem that inlining creates.
## When to use a Base64 image (the decision matrix)
The whole decision comes down to a handful of factors. Here they are side by side:
| Factor | Lean toward inlining (Base64) | Lean toward a normal file |
|--------|-------------------------------|---------------------------|
| **Size** | Under ~2 KB (green) | Over ~10 KB (red); 2–10 KB is a judgment call (amber) |
| **Reuse** | One page, a place or two | Repeated across many pages |
| **Change frequency** | Almost never changes | Edited often |
| **Context** | HTML email, self-contained widget or bookmarklet, JSON/API payload, a critical above-the-fold icon worth one saved request | Content images, shared cacheable assets |
Those size thresholds are not arbitrary. They mirror the traffic-light badge built into the [Image to Base64 converter](/tools/image-to-base64): green under 2 KB, amber up to 10 KB, red above. The tool reads your actual file and tells you which bucket it lands in.
### A simple rule of thumb
If you remember one line, make it this: **under ~2 KB and used in only one or two places, inlining usually pays off; over ~10 KB or reused across pages, a normal cached file almost always wins.** The 2–10 KB middle is where you weigh the saved request against the lost cache for your specific situation.
### Good fits in detail
A few cases where Base64 genuinely earns its keep:
- **HTML email.** Many email clients block externally hosted images by default for privacy, which breaks any layout that depends on a remote logo. A small inlined data URI renders immediately with no server fetch. Keep these to logos and icons; never inline a photograph into an email.
- **Self-contained widgets and bookmarklets.** A bookmarklet or an embeddable widget has to work with zero external dependencies. Inlining its icons keeps everything in a single droppable file.
- **JSON and API payloads.** Shipping a thumbnail inside a JSON document or a config file is sometimes the cleanest option: one round trip, one object, no second request to wire up.
- **A critical above-the-fold icon.** When a tiny logo is part of your Largest Contentful Paint and you want to shave one request off the critical path, inlining can help. Emphasis on *tiny*.
One pattern ties these together: in each case the asset travels *with* something else and would otherwise need its own delivery channel. An email cannot rely on your CDN, a bookmarklet has no second file to fetch, and a JSON response arrives as a single payload. So the alternative to inlining here is not a cached file but a missing image, which changes the calculus entirely. The useful question for a Base64 fit is not only whether the asset is small, but whether a separate file is even an option in the first place.
## When NOT to inline: caching, lazy loading, and Core Web Vitals
The flip side is longer, because inlining quietly disables several things the browser does well.
**You lose independent caching.** This stings most for returning visitors. A normal image sits in their cache after the first visit and loads instantly forever after. An inlined image has no independent cache entry; it rides along with the document every single time, so a repeat visitor pays the byte cost again and again.
**You lose lazy loading.** The `loading="lazy"` attribute lets the browser defer images that are below the fold until the user scrolls near them. A data URI is parsed and "downloaded" the instant the HTML is read, so there is nothing to defer. Inline a dozen below-the-fold images and you have forced all of them into the initial load.
**You enlarge render-blocking resources.** As noted earlier, a data URI inside CSS bloats a resource that blocks first paint. The bigger that stylesheet, the longer the page sits blank.
**Decoding is more expensive on mobile.** A data URI is Base64-decoded every time its document loads, and on low-end phones that extra CPU work adds up. Worse, the bytes never land in the browser's disk cache, so a heavy inlined image is re-decoded on each visit instead of being cached and decoded once like a normal file.
There is also a historical reason this advice has shifted. The original case for inlining, made loudly in the HTTP/1.1 era, was request reduction: each connection could fetch one resource at a time, so a page with 40 small icons paid 40 round trips. HTTP/2 changed that by multiplexing many requests over a single connection, which made extra small files cheap. The big payoff of inlining, fewer requests, mostly evaporated, while the costs stayed: lost caching, no lazy loading, bigger render-blocking files. If you read older articles enthusiastic about Base64 sprites, weigh them against the protocol your site actually runs on today.
### The Core Web Vitals angle
Inlining cuts both ways on LCP ([Largest Contentful Paint](https://web.dev/articles/lcp)). For a small, above-the-fold image that *is* the LCP element, removing a request can nudge LCP earlier. But inline a large image and you do the opposite: you delay the document or stylesheet it lives in, pushing LCP later for the whole page. The size threshold decides which way it goes.
For CLS (Cumulative Layout Shift), inlining changes nothing about the core rule: an image still needs explicit `width` and `height` (or an aspect-ratio box) so the browser can reserve space before it renders. A data URI without dimensions shifts layout exactly like a remote image without dimensions.
A better lever than inlining is usually shrinking the source. Compressing an image before you encode it makes both the file and any resulting data URI smaller. The [browser vs Node image compression guide](/blog/image-compression-browser-vs-node) covers how to do that client-side or in a build step, and [WebP vs AVIF vs JPEG](/blog/webp-vs-avif-vs-jpeg-image-format-guide) helps you pick a format that is small to begin with.
## How to inline images in HTML, CSS, Markdown, and JSON
Once you have a data URI, here is how it drops into each context. These are the four ready-to-paste snippets the [Image to Base64 converter](/tools/image-to-base64) generates for you.
**HTML**: paste the URI into any `src`:
```html
```
**CSS**: wrap it in `url()` for a `background-image` (this is the canonical base64 image in CSS pattern):
```css
.icon {
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");
}
```
**Markdown**: a self-contained image link for READMEs, GitHub issues, and notebooks where you cannot host a file:
```markdown
```
**JSON**: an embedded asset inside an API or config payload:
```json
{ "icon": "data:image/png;base64,iVBORw0KGgo…" }
```
All four work anywhere a URL is accepted: `img src`, CSS `background`, `mask-image`, even a favicon ``. Every modern browser supports the `data:` scheme.
### Generating these quickly
Building these by hand is error-prone: one wrong MIME type or a stray line break and the image silently fails to render. Drop your file into the [Image to Base64 converter](/tools/image-to-base64) and it produces all four snippets with their own copy buttons, plus the exact size increase so you know up front whether the asset belongs inline at all.
## SVG: the special case where Base64 usually loses
SVG breaks the usual logic, because SVG is text, not binary. Base64 exists to make binary data text-safe, but SVG is already XML text. Encoding it as Base64 just inflates a string that did not need encoding, and makes it unreadable in the process. So for SVG specifically, Base64 is almost always the wrong choice.
Compare three ways to inline the same icon:
```css
/* 1. Base64 data URI — adds the 33% tax to text that didn't need it */
.a { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…"); }
/* 2. URL-encoded data URI — percent-encode a handful of characters, no 33% tax */
.b { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'…%3C/svg%3E"); }
/* 3. Inline
${safe}
`; // renders as literal text // --------------------------------------------------------------- // In practice, prefer the platform's built-in escaping where it exists: // - React / Vue / Angular escape interpolated text by default // - Use textContent instead of innerHTML when you only need text: // el.textContent = userInput; // the browser escapes for you // - Server frameworks (Jinja, ERB, Blade) auto-escape unless you opt out ``` #### FAQ **Q: Is my text sent to your server when I encode it?** A: No. Every character is encoded entirely in your browser with JavaScript — open DevTools → Network and you will see zero requests fire when you type or paste. Nothing is uploaded, nothing is logged, nothing is written to disk. That privacy matters because the markup people escape is often sensitive: a snippet from a private CMS, an internal email template, a customer support reply, or a draft blog post you have not published. On a server-side encoder every one of those would travel across the network to a machine you do not control; here the text never leaves the tab. This is the whole reason to escape HTML client-side rather than paste it into a website that could, in principle, keep a copy of everything it processes. **Q: What does it mean to escape HTML, and why would I do it?** A: Escaping HTML means replacing characters that the browser would otherwise interpret as markup with their entity equivalents, so they are displayed as literal text instead. The classic case is showing code on a page: if you want a visitor to read the string <strong>bold</strong> rather than see the word "bold" rendered in boldface, you escape the angle brackets to <strong>bold</strong>. The other, more important case is security: when you insert untrusted user input into a page, escaping the five reserved characters (< > & " ') prevents that input from breaking out of its context and injecting a <script> tag — the core defense against cross-site scripting (XSS). Any text that originates from a user and lands in your HTML should be escaped first. **Q: What is the difference between named, decimal, and hex entities?** A: All three produce the same character; they differ only in how the reference is written. A named entity uses a human-readable label — < for <, & for &, © for © — which is easy to read but only works for characters that have a defined name. A decimal numeric entity writes the Unicode code point in base 10, like < for < or é for é. A hexadecimal entity writes the same code point in base 16, like < for < or é for é, mirroring the U+XXXX notation in the Unicode standard. Named entities are the most readable and are the right default for the common reserved characters; numeric entities (decimal or hex) can encode any code point, including ones with no name, which makes them the safe choice when you cannot guarantee the consumer supports a particular named entity. **Q: Why is the apostrophe encoded as ' and not '?** A: Because ' is not safe everywhere. The named entity ' was only introduced in HTML5 and XML — it is not defined in HTML4, so a few older parsers and email clients render it as the literal text "'" instead of an apostrophe. The numeric reference ' (or its decimal twin ') maps to the exact same character, U+0027, and is understood by every conforming parser ever written. Following the behavior of well-tested libraries like he, this tool emits the universally compatible ' for the apostrophe so the output is safe to drop into any HTML, XML, or attribute context without surprises. **Q: Do I need to encode non-ASCII characters like é, — or 😀?** A: Usually no. If your page declares <meta charset="utf-8"> — which essentially every modern page does — then accented letters, em dashes, and emoji are perfectly valid as raw UTF-8 and need no encoding at all. That is why the default "special characters" mode leaves them untouched, keeping your output short and readable. You only need to encode non-ASCII characters when the text will be served or stored in a legacy single-byte charset, or passed through a system that corrupts raw UTF-8. For those cases tick "Encode all non-ASCII characters" and every code point above 0x7F is converted to an ASCII-safe entity. When in doubt, keep the default and make sure your charset declaration is correct. **Q: Does escaping HTML protect me from XSS attacks?** A: Escaping is the foundation of XSS defense, but it is context-dependent, so the honest answer is "yes, when applied correctly." Encoding the five reserved characters before you place untrusted input into HTML element content reliably stops an attacker from injecting tags or scripts — a payload like <script>alert(1)</script> becomes inert text. The caveat is that HTML has several contexts, each with its own escaping rules: inside an attribute value you must escape quotes (which this tool does), inside a <script> block or an inline event handler you need JavaScript escaping instead, and inside a URL you need URL encoding. Use HTML entity encoding for HTML and attribute contexts; for URLs reach for the URL Encoder / Decoder, and for embedding a string in JavaScript or JSON see the JSON Escape tool. Encode at output time, in the context where the data lands. **Q: How do I reverse this — turn entities back into characters?** A: Use the companion HTML Entity Decoder. It takes a string full of entities like <div> & © and converts it back to the real characters <div> & ©, handling named entities, decimal references, hexadecimal references, and even legacy unterminated entities such as © without a trailing semicolon. Encoding and decoding are exact inverses for the reserved characters, so you can round-trip text through both tools without loss. If you are debugging why a page shows literal < instead of <, the decoder is the fastest way to see what the entities actually resolve to. **Q: Will encoding change the visible text or break my layout?** A: No — that is the entire point. An entity is just an alternate spelling of a character: when a browser parses < it renders a single < glyph, identical to the raw character. So a correctly escaped page looks exactly the same to a visitor as it would with raw characters; the only difference is that the browser treats the escaped version as text rather than markup. The one thing escaping changes is the length and appearance of the source string, which is why you escape only what needs escaping. If your goal is to clean up and indent messy markup rather than escape it, that is a different job — use the HTML Formatter instead. --- ### HTML Formatter, Beautifier & Minifier URL: https://go-tools.org/tools/html-formatter Format, beautify and minify HTML instantly in your browser. Indent messy markup or compress it to ship — free, private, and your HTML never leaves your device. #### What is HTML Formatting? HTML formatting (also called beautifying or pretty-printing) rewrites markup with consistent nesting, indentation and line breaks so its structure is easy to read and edit. The page renders identically before and after — only whitespace changes. Minifying does the reverse: it removes comments and collapses whitespace — including embedded CSS and JS — so pages load faster. This tool does both, entirely in your browser. #### FAQ **Q: How do I format HTML online?** A: Paste your HTML into the input box and click Format. The tool reindents the markup with proper nesting and line breaks, then lets you copy it. Everything runs locally in your browser — nothing is uploaded. **Q: How do I minify HTML?** A: Paste your HTML and click Minify. The tool removes comments and collapses whitespace — including embedded CSS and JavaScript — to produce the smallest equivalent markup, and shows how many bytes you saved. **Q: What is the difference between formatting and minifying HTML?** A: Formatting (beautifying) adds indentation and line breaks to make markup readable. Minifying strips comments and whitespace to shrink the file for faster loading. Both render identically in the browser. **Q: Does formatting change how my page renders?** A: Formatting only adds whitespace, which is safe for normal markup. Be aware that whitespace-sensitive elements like pre and textarea can be affected by reformatting or aggressive minification — verify those after processing. **Q: Is my HTML safe with this tool?** A: Yes. All formatting and minifying happen locally in your browser using JavaScript — your HTML is never sent to any server, logged, or stored. That makes it safe for proprietary or unreleased markup, unlike server-side tools that receive a copy of everything you paste. **Q: Does it minify inline CSS and JavaScript?** A: Yes. The minifier compresses style and script contents too, so a single pass shrinks your whole document — markup, styles and scripts together. **Q: What indentation should I use for HTML?** A: Two spaces is the most common default and keeps diffs compact; four spaces can help with deeply nested layouts; tabs let each developer choose their width. Pick one and apply it consistently — this tool supports all three. --- ### HTML to Markdown Converter URL: https://go-tools.org/tools/html-to-markdown Convert HTML to clean Markdown in your browser — GFM tables, task lists, and links. Choose ATX/Setext headings and inline or reference links. Great for migrating web content or feeding LLMs. 100% private, no upload. #### What is HTML to Markdown Conversion? HTML to Markdown conversion takes a rendered HTML document — the tags, attributes, and nesting a browser displays — and rewrites it as Markdown, the lightweight plain-text format built for writing and version control. Where Markdown to HTML expands compact text into markup for display, this is the reverse and reductive direction: you start with rich, verbose HTML and distil it down to the small, readable set of conventions Markdown offers. Under the hood the converter parses your HTML into a DOM tree — the same node structure a browser builds — then walks that tree and emits the Markdown equivalent for each node it recognises. An <h2> becomes ## , a <strong> becomes **text**, a <ul> becomes a bulleted list, an becomes a link, a <table> becomes a GFM pipe table. Traversing a real DOM, rather than running regular expressions over the raw string, is what lets it handle nested lists, mixed inline formatting, and tables correctly instead of breaking on edge cases. You reach for this conversion when you are migrating out of HTML, not into it. Content trapped in a CMS, a WYSIWYG editor, an old web page, or a rich-text field is hard to diff, hard to review, and hard to move. Converting it to Markdown frees it into a format that lives happily in a Git repo, a static-site generator, or a notes app — and, increasingly, into a format that large language models read efficiently. The catch, which honest tools state plainly, is that the conversion is lossy: HTML can express things Markdown cannot, so some structure and every styling detail are deliberately discarded in exchange for clean, portable text. The reverse operation — Markdown back to HTML, for when you are ready to publish or preview — is just as useful. Switch to the Markdown → HTML tab or open the dedicated Markdown to HTML converter. ``` HTML in:Pricing
Plans start at $9/mo. See the details.
| Plan | Price |
|---|---|
| Pro | $9 |
.htpasswd file stores the credentials used by HTTP Basic Authentication. Each line is a single username:hash pair, where the hash is a one-way digest of the password — the plaintext is never stored. Web servers read this file to decide who may access a protected URL. On Apache, a .htaccess file (or a <Directory> block) references the .htpasswd file and prompts the browser for a username and password before serving the page.
The hash format depends on which algorithm produced it. Apache's htpasswd tool can emit several: bcrypt (lines starting with $2y$) is the strongest and is recommended for Apache, Docker Registry, and Caddy; apr1 (Apache MD5, starting with $apr1$) is the most portable and the safe default for nginx; SHA-1 (starting with {SHA}) is unsalted and considered insecure; crypt (traditional DES) is legacy and truncates at 8 characters; and plain stores the password in cleartext, which should never be used in production.
This generator runs entirely in your browser — no username, password, or hash is ever uploaded. If you need a strong password to go with your entry, use our Random Password Generator. To build the Authorization: Basic header by hand, the credential is just base64(user:password), which you can produce with our Base64 Encoder. And once your endpoint is protected, test it from the command line with our cURL Command Builder.
```
# Apache htpasswd CLI equivalents (apache2-utils / httpd-tools)
# bcrypt entry, printed to stdout (recommended; -B = bcrypt, -n = no file, -b = password on CLI)
htpasswd -Bbn admin 's3cret'
# → admin:$2y$10$N9qo8uLOickgx2ZMRZoMye...
# apr1 (Apache MD5) entry, portable for nginx — no apache2-utils needed
printf "admin:$(openssl passwd -apr1 's3cret')\n"
# → admin:$apr1$k3l4Hj9.$qN8...
# Append a user to an existing file from the shell
htpasswd -B /etc/apache2/.htpasswd alice
# Note: nginx delegates bcrypt to the system crypt(); on Alpine/musl or old
# glibc that fails — prefer apr1 for nginx to stay portable.
```
#### FAQ
**Q: bcrypt vs apr1 — which should I choose?**
A: Use bcrypt for Apache, Docker Registry, Caddy, and Traefik — it's a strong, salted, adaptive hash and is the modern standard. Use apr1 (Apache MD5) for nginx, because nginx hands bcrypt off to the system crypt() and that fails on many builds, while apr1 is implemented internally and works everywhere. If you control the runtime and know bcrypt is supported, bcrypt is always the stronger choice; apr1 is about portability, not security.
**Q: Does nginx support bcrypt?**
A: Only indirectly, and not reliably. nginx doesn't hash passwords itself — for $2y$ entries it delegates verification to the C library's crypt() function, so support depends entirely on your libc. Alpine's musl and older glibc builds don't include the blowfish (bcrypt) scheme, so authentication silently fails. For portable nginx setups, use the apr1 format instead, which nginx verifies internally on every platform.
**Q: How do I fix the nginx error `crypt_r() failed (22: Invalid argument)`?**
A: That error means nginx tried to verify a bcrypt ($2y$) hash on a libc that doesn't support the blowfish scheme — typically Alpine/musl or an older glibc. The fix is to regenerate the entry as apr1 (Apache MD5) instead of bcrypt, which nginx verifies internally on any platform. Alternatively, switch to a base image whose libc includes bcrypt support, but apr1 is the simpler, portable solution.
**Q: Where should I put the .htpasswd file and what permissions?**
A: Store the .htpasswd file outside the web document root so it can never be served as a static file and exposed. A common location is /etc/apache2/.htpasswd or /etc/nginx/.htpasswd. Set permissions to 640 (chmod 640) and make it owned by the user the web server runs as (for example www-data or nginx), so the server can read it but other accounts cannot.
**Q: How do I configure Basic Auth in .htaccess / nginx?**
A: For Apache, this tool generates a .htaccess block with AuthType Basic, AuthName, AuthUserFile pointing at your .htpasswd path, and Require valid-user. For nginx, it generates a location block with auth_basic "Restricted"; and auth_basic_user_file /path/.htpasswd;. Copy the config block that matches your server, adjust the file path, and reload — the snippets are ready to paste.
**Q: Are my passwords uploaded anywhere?**
A: No. Every hash is computed entirely in your browser using JavaScript — no username, password, or generated hash is ever sent over the network. You can confirm this by opening your browser's Developer Tools (F12 → Network tab) while generating: there are zero outgoing requests. Nothing is stored or logged on any server, so it's safe to generate real production credentials here.
**Q: What's the difference between $2a$, $2b$, and $2y$ in bcrypt?**
A: They are version prefixes for the same bcrypt algorithm and produce equivalent hashes; the differences trace back to historical bug fixes in how certain implementations handled high-bit characters and string length. Apache's htpasswd emits $2y$. Modern bcrypt libraries treat $2a$, $2b$, and $2y$ as interchangeable for verification, so a $2y$ entry generated here will validate correctly in Apache, Caddy, Traefik, and Docker Registry.
**Q: What bcrypt cost should I use?**
A: Cost 12 is the modern default and a good balance of security and speed. The cost is a work factor: each increment doubles the time to compute and verify the hash, which slows down brute-force attacks but also adds latency to every login. Cost 10 is acceptable for low-traffic or low-risk endpoints; 12–14 is recommended for anything sensitive. Avoid going so high that legitimate authentication becomes noticeably slow.
**Q: htpasswd vs the Authorization: Basic header — what's the difference?**
A: They sit on opposite ends of the same exchange. The .htpasswd file holds the server-side stored hash — a one-way digest the server uses to verify credentials. The Authorization: Basic header is the client-side request credential: the literal base64 of username:password the browser or curl sends on each request. The server base64-decodes the header, then checks the password against the stored hash. One is storage, the other is transport.
**Q: I don't have apache2-utils installed — how do I generate an htpasswd entry?**
A: You don't need it — this tool generates valid bcrypt, apr1, and SHA-1 entries entirely in your browser. If you prefer the command line, OpenSSL ships on almost every system: run openssl passwd -apr1 to produce an apr1 hash, then prefix it with username: to form the line. On Debian/Ubuntu you can also install the htpasswd binary via apt install apache2-utils, or httpd-tools on RHEL/CentOS.
**Q: What do the htpasswd flags -B, -Bbn, -bnB mean?**
A: Each letter is an independent flag: -B selects bcrypt, -n prints the result to stdout instead of writing a file, and -b takes the password as a command-line argument (rather than prompting). The order doesn't matter, so -Bbn and -bnB are identical. -Bbn is the common combination for piping a bcrypt entry into a Docker Registry htpasswd file.
**Q: Why does Docker Registry require bcrypt?**
A: The Docker Registry's htpasswd authentication backend only accepts bcrypt-formatted entries; apr1, SHA-1, and crypt hashes are rejected and login will fail. Generate the entry with htpasswd -Bbn user password (or use the bcrypt option here), mount the file into the registry container, and point REGISTRY_AUTH_HTPASSWD_PATH at it. Always pair this with TLS, since Basic Auth credentials are otherwise readable in transit.
**Q: Is Basic Auth secure?**
A: Only over HTTPS. HTTP Basic Auth sends credentials as base64(username:password) on every request, and base64 is reversible encoding — not encryption — so anyone who can read the traffic can recover the password instantly. Over TLS the header is encrypted in transit and Basic Auth is acceptable for simple gating. Never use it on plain HTTP, and prefer stronger schemes for high-value applications.
---
### IEEE 754 Floating-Point Converter
URL: https://go-tools.org/tools/ieee-754-converter
Convert floats to IEEE 754 hex & binary, or decode hex to float — FP16, FP32, FP64 and bfloat16. See the exact stored value, rounding error and bit layout. 100% in your browser.
#### What Is IEEE 754 Floating Point?
IEEE 754 is the standard that defines how computers store real numbers in binary. Every value is packed into three fields: a sign bit, an exponent (stored with a bias so it can represent both large and tiny magnitudes), and a mantissa holding the significant digits. Almost every CPU, GPU, and programming language uses it, which is why the same rounding surprises appear in JavaScript, Python, C, and SQL alike.
The key insight is that binary floating point can only represent numbers of the form m × 2ⁿ. Decimal fractions like 0.1 are infinite repeating fractions in base 2 — 0.000110011001100… — so the format stores the nearest representable neighbor instead. In single precision that neighbor is 0.100000001490116119384765625; in double precision it is 0.1000000000000000055511151231257827021181583404541015625. Neither is 0.1. Every downstream oddity — 0.1 + 0.2 ≠ 0.3, sums that drift, equality checks that fail — follows from this single fact, and this converter makes it visible by printing the exact stored value rather than a rounded-back approximation. The same drift shows up whenever floats round-trip through JSON — inspect the payload with the JSON formatter and the bits here.
The standard also reserves bit patterns for special values. An all-ones exponent encodes ±Infinity (mantissa zero) or NaN (mantissa non-zero); an all-zeros exponent encodes signed zero (mantissa zero) or subnormal numbers (mantissa non-zero), which fill the underflow gap next to zero at reduced precision. The four formats this tool covers — binary16/FP16, bfloat16, binary32/FP32, binary64/FP64 — differ only in how many bits they give each field: more exponent bits mean more range, more mantissa bits mean more precision. bfloat16, the machine-learning favorite, is simply FP32 with the bottom 16 mantissa bits cut off: same range, much coarser precision.
A useful mental model is that representable floats form a grid on the number line whose spacing — one unit in the last place, or ULP — doubles at every power of two. Near 1.0 a double's grid spacing is about 2.22 × 10⁻¹⁶; near 2⁵³ it is a whole integer, which is why doubles cannot count beyond 2⁵³ reliably. The neighbors panel in this tool shows that grid directly: the previous and next representable values around whatever you type, with the exact gap between them.
```
// Float ↔ hex through the raw IEEE 754 bits (works in any browser / Node.js)
const buf = new DataView(new ArrayBuffer(8));
function floatToHex32(value) {
buf.setFloat32(0, value); // rounds to nearest even
return '0x' + buf.getUint32(0).toString(16).toUpperCase().padStart(8, '0');
}
function hexToFloat32(hex) {
buf.setUint32(0, parseInt(hex, 16));
return buf.getFloat32(0);
}
floatToHex32(0.1); // '0x3DCCCCCD'
floatToHex32(3.14159); // '0x40490FD0'
hexToFloat32('3DCCCCCD'); // 0.10000000149011612
```
#### FAQ
**Q: Why is 0.1 + 0.2 not equal to 0.3?**
A: Because 0.1, 0.2 and 0.3 have no exact binary representation — a double stores the nearest representable value instead. 0.1 and 0.2 are each stored slightly high, so their sum lands one bit above the stored 0.3: bit pattern 0x3FD3333333333334 versus 0x3FD3333333333333, which is why 0.1 + 0.2 == 0.3 is false in JavaScript, Python, Java, C, Rust and Go. The double behind 0.1 is exactly 0.1000000000000000055511151231257827021181583404541015625, and the sum stored for 0.1 + 0.2 is 0.3000000000000000444089209850062616169452667236328125 — type 0.1 into this converter to read the stored value digit for digit.
**Q: What is IEEE 754?**
A: IEEE 754 is the technical standard for binary floating-point arithmetic used by virtually every modern CPU, GPU, and programming language. It defines how a number is packed into bits — one sign bit, an exponent field, and a mantissa (significand) — plus the rounding rules and the special values Infinity, NaN, signed zero, and subnormals. The formats you will meet in practice are binary32 (float, FP32), binary64 (double, FP64), binary16 (half, FP16), and the related bfloat16 truncation used in machine learning. This converter shows all four at the bit level.
**Q: What is the difference between FP16 and bfloat16?**
A: Both are 16-bit formats, but they split their bits differently. FP16 (IEEE binary16) uses 5 exponent bits and 10 mantissa bits: more precision, but a tiny range — the largest finite value is 65504, so overflow to Infinity is a constant hazard. bfloat16 keeps FP32's 8 exponent bits and only 7 mantissa bits: the full ±3.4 × 10³⁸ range of a float, with much coarser precision. That is why ML training, where gradients can spike far beyond 65504, standardized on bfloat16, while FP16 suits storage and inference where values are tamed. Compare them here: type 0.1 and switch formats — FP16 stores 0.0999755859375 (0x2E66), bfloat16 stores 0.10009765625 (0x3DCD).
**Q: What are subnormal (denormal) numbers?**
A: When the exponent field is all zeros, IEEE 754 drops the implicit leading 1 and lets the mantissa shrink gradually toward zero — these are subnormal (older term: denormal) numbers. They fill the gap between zero and the smallest normal number, so the difference of two unequal floats can never round to zero (gradual underflow). The cost is reduced precision and, on many CPUs, slower arithmetic. In FP16 the smallest subnormal is 2⁻²⁴ = 0.000000059604644775390625; click the Min subnormal chip in any format to inspect its bit pattern — exponent bits all zero, mantissa 0…001.
**Q: Should I use float or double?**
A: Default to double (FP64) unless you have a measured reason not to. A double carries about 15–16 significant decimal digits versus roughly 7 for a float, and most languages (JavaScript numbers, Python floats) are double-only anyway. Choose float (FP32) when memory bandwidth or storage dominates — large arrays, GPU pipelines, graphics — and you have confirmed 7 digits are enough. For money, use integers (cents) or a decimal type instead: no binary format stores 0.1 exactly, as the stored-value panel of this tool demonstrates. If you need to inspect integer bases instead, see the number base converter.
**Q: How do I convert a float to hex by hand?**
A: Take the sign (0 for positive, 1 for negative). Write the absolute value in binary and normalize it to 1.xxx × 2ⁿ. Add the format's bias to n (127 for FP32, 1023 for FP64) and write that in the exponent bits. Drop the leading 1 and keep the next 23 (or 52) bits of the fraction as the mantissa, rounding to nearest even at the cut. Concatenate sign, exponent, mantissa and group each 4 bits into one hex digit. For 3.14159 in FP32 that yields 0 | 10000000 | 10010010000111111010000 → 0x40490FD0 — the same steps with bias 1023 and 52 mantissa bits turn a double to hex — or skip the arithmetic and let this converter do each step visibly.
**Q: Is my data uploaded when I use this converter?**
A: No. Every conversion runs locally in your browser using plain JavaScript — DataView and BigInt arithmetic, no server round-trip, no third-party libraries. You can open your browser's developer tools, watch the network panel stay silent while you type, or disconnect from the internet entirely and keep converting. The Copy link button encodes the bit pattern into the URL fragment, which is likewise never sent to any server.
---
### Compress Images Online — JPEG, PNG & WebP
URL: https://go-tools.org/tools/image-compressor
Compress JPEG, PNG, WebP & AVIF up to 80% smaller — in your browser, no upload. Batch 20 images, resize, compare before & after, download as ZIP. Free & private.
#### What Is Image Compression?
Image compression reduces file size by removing redundant or imperceptible visual data, enabling faster page loads and reduced bandwidth consumption. According to the HTTP Archive Web Almanac, images account for approximately 50% of total page weight on average — making image optimization one of the highest-impact performance improvements available to web developers.
As Google's web performance guidance notes, optimizing images is consistently among the top recommendations from Lighthouse and PageSpeed Insights, directly improving Core Web Vitals metrics such as Largest Contentful Paint (LCP). The WebP specification (Google, 2010) demonstrated that modern compression algorithms can reduce image file sizes by 25–35% compared to JPEG at equivalent visual quality, a finding that has since driven widespread adoption of next-generation formats (HTTP Archive, WebP specification).
There are two main compression approaches:
**Lossy compression** discards some image data to achieve smaller file sizes. JPEG and WebP use lossy compression by default — a quality setting of 75% typically reduces file size by 60–80% with minimal visible difference. The tradeoff is irreversible: once data is discarded, it cannot be recovered from the compressed file.
**Lossless compression** reduces file size without discarding any data. PNG uses lossless compression by default — the decompressed image is bit-for-bit identical to the original. The compression ratio is lower (typically 10–30%), but image quality is perfectly preserved.
This tool compresses your images entirely in your browser — your images are never uploaded to any server, at any point. For JPEG and WebP files, the quality slider directly controls the lossy compression level through the Canvas API. PNG files come back as PNG: because the Canvas API cannot encode a lossy PNG, the tool compresses them with palette quantization instead, which trims the number of distinct colors and keeps transparency intact, including soft anti-aliased edges. If you want a different container, the output format selector lets you request PNG or WebP for any input. Every compression operation stays on your device, giving you the performance gains without the privacy cost.
For embedding small compressed images directly in HTML or CSS, you can Base64-encode the output to create data URIs — a common technique for icons and logos under 5 KB. For a deeper comparison of browser-based vs Node.js compression solutions — including Squoosh, Sharp, and Imagemin — read our image compression guide.
```
// Compress a JPEG image in the browser using the Canvas API
async function compressImage(file, quality = 0.75) {
const img = await createImageBitmap(file); // decode the image
const canvas = document.createElement('canvas');
canvas.width = img.width;
canvas.height = img.height;
canvas.getContext('2d').drawImage(img, 0, 0);
// quality: 0.0 (smallest file) → 1.0 (original quality)
return new Promise((resolve) =>
canvas.toBlob(resolve, 'image/jpeg', quality)
);
}
// file comes from an or drag-and-drop
const blob = await compressImage(file, 0.75);
console.log(`Original: ${file.size} bytes`);
console.log(`Compressed: ${blob.size} bytes`);
// → Original: 2100000 bytes
// → Compressed: 672000 bytes (~68% reduction)
```
#### FAQ
**Q: Is it safe to compress images online?**
A: Yes — this tool is completely safe because it processes images entirely in your browser. Your images are never uploaded to any server. The compression uses the browser's built-in Canvas API, and all data stays on your device. You can verify this by opening your browser's Network tab in Developer Tools — you will see zero network requests during compression. When you close or refresh the page, all image data is cleared from memory.
**Q: What is the difference between lossy and lossless compression?**
A: **Lossy compression** permanently removes some image data to achieve smaller file sizes. JPEG and WebP use lossy compression — a quality setting of 75 typically reduces file size by 60–80% with minimal visible difference, but the removed data cannot be recovered.
**Lossless compression** reduces file size without removing any data. The decompressed image is bit-for-bit identical to the original. PNG uses lossless compression. The tradeoff is that lossless compression achieves smaller reductions (typically 10–30%).
For web use, lossy compression at quality 75–85 is almost always the right choice — the file size savings are dramatic and the quality difference is imperceptible to most viewers.
**Q: Do my PNG files stay PNG?**
A: Yes. A PNG you upload comes back as a PNG. The browser's Canvas API cannot encode a lossy PNG, so rather than change the format, this tool quantizes the image to a color palette — it reduces the number of distinct colors and writes a real PNG back out, with transparency preserved, including soft anti-aliased edges.
If you do want a WebP, pick **WebP** in the output format selector above the file list. **Same as input** is the default and leaves every file in its own format; **PNG** forces PNG output even for JPEG or WebP input.
At quality 100 the PNG is re-encoded losslessly, so no pixels change and the size reduction depends entirely on how efficiently your original was already encoded — it can be zero. Whenever the result is not smaller than the file you uploaded, the tool discards it and keeps your original.
**Q: What quality setting should I use?**
A: It depends on your use case:
- **Quality 85–95**: Visually indistinguishable from the original. Use for professional photography, portfolio sites, or anywhere image quality is critical. Typical reduction: 30–50%.
- **Quality 70–85**: Excellent quality with significant size savings. The recommended range for most web use. Typical reduction: 50–75%.
- **Quality 50–70**: Good quality with aggressive compression. Suitable for thumbnails, social media, and images viewed at small sizes. Typical reduction: 70–85%.
- **Quality below 50**: Noticeable artifacts. Only use when file size is more important than quality (e.g., email constraints, very low bandwidth).
Use the Compare button to find the lowest quality that looks acceptable for your specific image.
**Q: Can I compress images without losing quality?**
A: Technically, yes — set the quality slider to 100 for lossless compression. However, the file size reduction will be minimal (0–10% for most images) because lossless compression can only remove redundant encoding data, not image data.
In practice, quality 80–85 is effectively "no visible quality loss" for most images. The human eye cannot distinguish between quality 85 and quality 100 in typical viewing conditions. The Compare slider lets you verify this for your specific image.
For maximum file size reduction without visible quality loss, start at quality 75 and use the Compare button to check. If you see artifacts, increase the quality in increments of 5 until the result looks acceptable.
**Q: How many images can I compress at once?**
A: You can compress up to 20 images in a single batch. Each image can be up to 10MB in size. All processing happens in your browser, so performance depends on your device's CPU and available memory.
For large batches of high-resolution images, compression may take a few seconds. The tool processes all images and shows a per-file progress indicator and the total space saved.
**Q: What happens if the compressed file is larger than the original?**
A: This can happen with images that are already well-optimized, or when compressing at very high quality settings (90–100). The tool then keeps your original file and shows "0% saved", with a tooltip explaining why nothing was replaced.
If this happens, the original image was likely compressed with an advanced encoder (like mozjpeg, cjpeg, or pngquant) that is more efficient than the browser's built-in encoder. In this case, your original file is already optimally compressed — no further action is needed.
**Q: Does compression change my image dimensions?**
A: By default no — pixel dimensions are preserved. A 4000×3000 image stays 4000×3000 after compression and only the file size changes.
If you want to resize, set a max width in pixels and keep the **Keep aspect ratio** checkbox enabled. The image is downscaled (never upscaled) and height is derived from the original aspect ratio. Resizing and compression compound — a 4000 px photo dropped to 1600 px max width before quality 75 compression often shrinks 5–10× total.
**Q: What image formats are supported?**
A: This tool supports four formats:
- **JPEG** (.jpg, .jpeg): The most common format for photographs. Supports lossy compression with the quality slider.
- **PNG** (.png): Best for graphics with transparency. Compressed by palette quantization and saved as PNG, with transparency preserved.
- **WebP** (.webp): Modern format with the best compression efficiency. Supports both lossy compression and transparency.
- **AVIF** (.avif): Next-generation format with the best compression ratios in 2026. AVIF input is supported on every modern browser; AVIF encode (re-saving as AVIF) requires Chrome 85+ — on browsers without AVIF encode, AVIF input is transparently re-encoded as WebP.
Other formats (GIF, SVG, HEIC, TIFF) are not currently supported.
**Q: How does this compare to TinyPNG or Squoosh?**
A: The main difference is **privacy**: this tool processes images entirely in your browser — your files never leave your device. TinyPNG uploads images to their servers for processing.
**TinyPNG** uses server-side compression with advanced algorithms (pngquant for PNG, mozjpeg for JPEG) that can produce slightly smaller files than browser-based compression. However, your images must be uploaded to their servers, and the free tier limits you to 20 images per day at 5MB each.
**Squoosh** (by Google) also processes images in the browser using WebAssembly, offering more codecs and finer control. This tool is simpler and faster for the common case of batch-compressing JPEG, PNG, and WebP files with a single quality setting.
Choose this tool when privacy is a priority, you need quick batch compression, and you don't need advanced codec options.
---
### Image to Base64 Converter
URL: https://go-tools.org/tools/image-to-base64
Convert images to Base64 data URIs in your browser — PNG, JPG, GIF, WebP, SVG, ICO. Copy HTML, CSS, Markdown & JSON, with the exact size increase. 100% private, no upload.
#### What is a Base64 Image (Data URI)?
A Base64 image is a picture whose binary bytes have been re-encoded as a string of printable ASCII characters using the Base64 alphabet (A–Z, a–z, 0–9, + and /). Wrapped in the data: URI scheme — data:image/png;base64,iVBORw0KGgo… — that string can appear anywhere a URL is expected: an HTML img src, a CSS background-image, an email body, or a field inside a JSON payload. The browser decodes it on the fly and displays the image with no separate network request. This is why Base64 images are sometimes called "inline" or "embedded" images.
The encoding exists for a simple reason: many systems were built to carry text, not arbitrary binary. HTML, JSON, email headers, and URLs all expect characters, and raw image bytes would include control codes and delimiters that break them. Base64 maps every 3 binary bytes onto 4 safe text characters, guaranteeing the data survives transport intact. The cost is size: the text representation is about 33% larger than the original binary, and it cannot be cached independently of the document that contains it.
That trade-off defines when Base64 images make sense. For a tiny icon used in one stylesheet, inlining removes a round trip and the size penalty is negligible — a clear win. For a 200 KB hero photo reused across every page, inlining bloats every page, defeats the browser cache, and costs CPU to decode on each load — a clear loss. The modern, HTTP/2-era guidance is to inline only small, stable assets and serve everything else as ordinary cached files. This tool surfaces the exact numbers for your image and a traffic-light recommendation so the decision is grounded in data, not folklore.
The reverse operation — turning a Base64 string back into a viewable, downloadable image — is equally useful when you are debugging a data URI from a stylesheet, inspecting an API response, or recovering an asset embedded in a config file. Switch to the Base64 → Image tab or open the dedicated Base64 to Image decoder.
```
/* CSS */
.badge {
background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==");
}
// JSON
{ "mime": "image/png", "data": "iVBORw0KGgo…" }
```
#### FAQ
**Q: What does this Image to Base64 converter do?**
A: It reads an image you drop, paste, or select and encodes its bytes as a Base64 string — entirely inside your browser. You get the raw Base64, a ready-to-use data URI (data:image/png;base64,…), and copy-paste snippets for HTML . For CSS, use the CSS tab, which wraps the data URI in background-image: url("data:image/png;base64,…"). Both work anywhere a URL is accepted — img src, CSS background, mask-image, even favicon link tags. The data: scheme is supported by every modern browser. One caveat: very long data URIs in inline HTML can hurt readability and, in CSS, bloat the stylesheet that ships to every visitor, so reserve inlining for genuinely small assets.
**Q: Which image formats are supported?**
A: PNG, JPEG/JPG, GIF (including animated), WebP, SVG, ICO, and BMP are all supported, plus AVIF where the browser can decode it. Because the tool encodes the raw bytes rather than re-rendering the image, animated GIFs stay animated, transparent PNGs keep their alpha channel, and SVGs remain fully scalable. The MIME type is read from the file itself and, when you paste raw Base64 into the decoder, inferred from the data's magic bytes. There is no format conversion during encoding — the output represents exactly the file you provided.
**Q: Why is SVG a special case?**
A: SVG is XML text, not binary, so Base64 actually makes it larger and harder to read for no benefit. For inlining SVG in CSS or HTML, URL-encoding the markup (percent-encoding a handful of characters like #, <, >, and quotes) is usually smaller than Base64 and keeps the source legible and gzip-friendly. This tool still offers Base64 SVG output because some pipelines require it, but if you are hand-optimizing CSS, prefer a URL-encoded data URI. Our URL Encoder/Decoder helps with that approach.
**Q: Is Base64 the same as encryption?**
A: No. Base64 is an encoding, not encryption — it is fully reversible by anyone with no key required. It exists to represent binary data using a safe set of printable ASCII characters so the data survives transport through systems that only handle text (HTML, JSON, email headers, URLs). Anyone can decode a Base64 string back to the original image in seconds, including with the Base64 → Image tab here. Never treat Base64 as a way to hide or protect sensitive image content; it provides zero confidentiality.
**Q: Can I embed a Base64 image in an email?**
A: Yes, and it is one of the better uses of the technique. Many email clients block externally hosted images by default for privacy, which breaks layouts that rely on remote logos. Embedding small images as data URIs ensures they render immediately without a server fetch. The trade-offs: some older clients (notably certain versions of Outlook) have spotty data-URI support, and large embeds inflate the message size that every recipient downloads. Keep embedded images small — logos and icons, not photographs — and test across your target clients.
**Q: Why does my Base64 image not render?**
A: The most common causes: a missing or wrong MIME type in the data: prefix (use image/png for PNG, image/jpeg for JPG, image/svg+xml for SVG), whitespace or line breaks accidentally inserted into the string, a truncated copy that dropped the trailing padding (= or ==), or pasting only the raw Base64 without the data:…;base64, prefix where a URL is expected. The decoder in this tool is tolerant — it strips whitespace, accepts input with or without the prefix, and infers the MIME from the image's magic bytes — so pasting your string into the Base64 → Image tab is the fastest way to confirm whether the data itself is valid.
---
### JavaScript Formatter & Minifier
URL: https://go-tools.org/tools/js-formatter
Format, beautify and minify JavaScript instantly in your browser. Clean up messy code or compress it with Terser to ship — free, private, and your code never leaves your device.
#### What is JavaScript Formatting?
JavaScript formatting (also called beautifying or pretty-printing) rewrites code with consistent indentation, spacing and line breaks so it's easy to read and review. The code behaves identically before and after — only whitespace changes. Minifying does the reverse: it shortens names, drops comments and collapses whitespace to produce the smallest bundle that runs the same. This tool does both, entirely in your browser.
#### FAQ
**Q: How do I format JavaScript online?**
A: Paste your code into the input box and click Format. The tool reindents it with consistent spacing and line breaks, then lets you copy it. Everything runs locally in your browser — nothing is uploaded.
**Q: How do I minify JavaScript?**
A: Paste your code and click Minify. The tool runs Terser to rename locals, remove comments and collapse whitespace into the smallest equivalent script, and shows how many bytes you saved.
**Q: What is the difference between formatting and minifying JavaScript?**
A: Formatting (beautifying) adds indentation and spacing to make code readable. Minifying shortens names and strips whitespace and comments to shrink the bundle for faster loading. Both run with the same behavior as the original.
**Q: Does minifying change what my code does?**
A: No. Terser preserves behavior — it only renames local variables and removes whitespace, comments and unreachable code. The minified script runs the same as the source.
**Q: Is my code safe with this tool?**
A: Yes. All formatting and minifying happen locally in your browser using JavaScript — your code is never sent to any server, logged, or stored. That makes it safe for proprietary or unreleased code, unlike server-side tools that receive a copy of everything you paste.
**Q: Why did minify report an error?**
A: Terser needs syntactically valid JavaScript. If you paste an incomplete snippet or TypeScript/JSX, parsing fails — format works on a best-effort basis, but minification requires valid JS. Fix the syntax or transpile first, then try again.
**Q: What indentation should I use for JavaScript?**
A: Two spaces is the most common default in modern JavaScript and keeps diffs compact; four spaces and tabs are also widely used. Pick one and apply it consistently — this tool supports all three when beautifying.
---
### JSON Diff & Compare
URL: https://go-tools.org/tools/json-diff
Compare two JSON files instantly in your browser. Side-by-side highlighting, RFC 6902 JSON Patch output, ignore noisy fields like timestamps and IDs. 100% private, no upload.
#### What is JSON Diff?
JSON Diff is a structural comparison of two JSON documents that respects JSON's data model — keys are unordered, types are strict, and arrays may be ordered or keyed. Unlike a text diff (which compares lines and reports key reorders or whitespace as differences), a JSON diff produces semantically meaningful results.
The canonical machine-readable form is JSON Patch (RFC 6902), an ordered ops array (add, remove, replace, move, copy, test) that transforms one document into another. Paths use JSON Pointer (RFC 6901). Closely related: JSON Merge Patch (RFC 7396) — simpler but cannot distinguish 'remove key' from 'set key to null'. This tool outputs RFC 6902.
Deep equality on JSON in JavaScript is harder than it looks. JSON.stringify(a) === JSON.stringify(b) fails on key reorder, misleads on -0 vs 0 (both stringify to "0"). A correct diff must walk both trees in parallel using key-set union, distinguish null from missing via the 'in' operator, and decide what 'equal' means for numbers (Object.is by default, epsilon for tolerance).
This tool runs entirely in your browser. Inputs never leave your machine. Safe for API responses, internal schemas, and proprietary configs.
Working with adjacent JSON tools? Format with JSON Formatter; convert with JSON to YAML, YAML to JSON, JSON to CSV, and CSV to JSON. See our guide for advanced timestamp/ID filtering patterns. Need to validate the structure (not just diff it)? See our JSON Schema validation guide.
```
// Two JSON documents that look different but are semantically equal
const a = '{"a":1,"b":2}';
const b = '{"b":2,"a":1}';
// Naive comparison — wrong
JSON.stringify(JSON.parse(a)) === JSON.stringify(JSON.parse(b));
// → false (key order differs)
// JSON Diff (this tool) — correct: key order is irrelevant
// → 0 differences
// JSON Patch (RFC 6902) for { "a": 1 } → { "a": 2 }
// [{ "op": "replace", "path": "/a", "value": 2 }]
```
#### FAQ
**Q: Why does my diff show everything changed when I only changed one field?**
A: Three usual suspects: (1) different key order — JSON Diff treats key order as equivalent, but text diff tools don't; (2) timestamps/UUIDs/auto-IDs that mutate on every request — add them to Ignore paths; (3) array order, when by-index comparison shouldn't apply — switch Array mode to 'Match by key'.
**Q: How do I ignore timestamps and IDs in JSON diff?**
A: Use the Ignore paths input above. Click the 'Timestamps' or 'IDs' preset for one-click filtering of /createdAt, /updatedAt, /*Id, /*At, /requestId. You can also paste your own Extended JSON Pointer patterns — one per line — for advanced filtering.
**Q: What's the difference between JSON Patch and a visual diff?**
A: Visual (side-by-side) diff is for humans — review changes by eye. JSON Patch (RFC 6902) is for machines — a structured ops array (add/remove/replace) you can apply with fast-json-patch or rfc6902 npm packages. Same diff, two outputs.
**Q: Does JSON diff treat null and missing keys the same?**
A: No. {"a":null} and {} differ — the first has an explicit null, the second has no key. Real systems behave differently for the two; this tool keeps them distinct.
**Q: How are arrays compared — by index or by key?**
A: By index (Sequential) by default. Switch to 'Match by key' and provide a key field (commonly id) to align elements regardless of order. Use this for K8s envs, package-lock entries, or any list that's logically a set.
**Q: Can I export the diff as RFC 6902 JSON Patch?**
A: Yes. The JSON Patch tab outputs a valid RFC 6902 ops array. If Ignore paths are set, the patch is filtered (the tab shows '(filtered: excludes N ignored paths)') and will not round-trip the originals exactly. Clear Ignore paths for a complete patch.
**Q: Is JSON Patch the same as JSON Merge Patch (RFC 7396)?**
A: No. RFC 6902 (JSON Patch) is an ordered ops array — explicit and reversible. RFC 7396 (Merge Patch) is a single merge document — simpler but cannot represent removal differently from setting null. JSON Diff outputs RFC 6902.
**Q: How do I compare two large JSON files (>10 MB)?**
A: Files over ~5 MB exceed practical browser memory. Live mode disables at 200 KB; for multi-megabyte files, use command-line jq or fast-json-patch in Node.
**Q: Does the tool send my JSON to a server?**
A: No. All comparison runs locally in your browser. Your JSON inputs are never written to disk, network, localStorage, or URL parameters. Only your preferences (ignore paths, array mode, numeric tolerance, active tab) are stored in localStorage so they persist across sessions. Refreshing the page clears the JSON inputs. The Share Link button writes only your config (Array mode, Ignore paths) — never your data.
**Q: Why does 42 differ from "42" in the diff?**
A: JSON Diff is type-strict: number 42 and string "42" are not equal. This catches backend serialization drift (some endpoints return numeric IDs, others return strings) — the diff labels it as 'type' modification.
**Q: Can I diff JSON with comments (JSONC) or trailing commas?**
A: Standard JSON (RFC 8259) does not allow comments or trailing commas. This tool uses native JSON.parse, which rejects both. Strip comments first using JSON Formatter.
**Q: How do I compare nested arrays of objects by a key like id?**
A: Set Array mode to 'Match by key' and enter id. Diff aligns by id values. v1 applies the same key field at every array depth; inner arrays without that field fall back to sequential and emit a warning chip.
**Q: Does the diff handle floating-point precision (0.1 + 0.2)?**
A: Yes, with Numeric tolerance. Default is 0 with Object.is — so -0 vs +0 are flagged. Set tolerance to a small epsilon (e.g. 1e-9) and 0.1 + 0.2 will compare equal to 0.3. Tolerance applies only to numeric leaves.
---
### JSON Escape
URL: https://go-tools.org/tools/json-escape
Escape any text or JSON into a valid JSON string literal in your browser. Handles quotes, newlines, tabs, Unicode, and slashes. 100% private, no upload, instant.
#### What is JSON Escaping and When Do You Need It?
JSON escaping is the process of converting a raw string into a form that is safe to embed inside a JSON document. JSON has a small set of characters that carry structural meaning — the double quote delimits strings, the backslash starts an escape sequence — plus control characters (newlines, tabs) that are not allowed to appear literally inside a string. Escaping replaces each of these with a safe two-character sequence (\", \\, \n, \t) or a \uXXXX Unicode escape, so the resulting string parses cleanly anywhere.
You reach for JSON escaping more often than you might think. The most common case is JSON-in-JSON: a webhook envelope, a message-queue payload, or an audit log stores a request body as a string field, which means the inner JSON must be escaped before it can be assigned. Another is hand-authoring JSON config: pasting a multi-line shell script, SQL query, or code snippet into a single JSON value requires turning every newline into \n. A third is building REST request bodies by hand in tools like curl, where a quoted JSON string must be escaped to survive the shell and the HTTP layer.
This tool has three differentiators over a naive escaper. First, it is built on the exact JSON specification rules — the same logic a compliant serializer uses — so output round-trips losslessly: escape here, parse anywhere, get your bytes back. Second, the optional ASCII-safe mode converts every non-ASCII character (including astral emoji, handled as surrogate pairs) to \uXXXX for systems that cannot be trusted with UTF-8. Third, everything runs 100% in your browser — your payloads, which often contain PII, tokens, and secrets, never touch a server. To reverse the process, use our JSON Unescape tool; to validate JSON first, see the JSON Formatter.
```
// Input text
She said "hi"
then left.
// Escaped (Wrap on) — identical to JSON.stringify(input)
"She said \"hi\"\nthen left."
// Escaped (Wrap off) — just the body, for hand-built JSON
She said \"hi\"\nthen left.
// JSON-in-JSON
{"a":1} -> "{\"a\":1}" -> {"payload": "{\"a\":1}"}
```
#### FAQ
**Q: What does this JSON escape tool do?**
A: It converts any text — a JSON object, a code snippet, a log line, or plain prose — into a valid JSON string literal, entirely in your browser. Special characters that would break a JSON document are escaped: double quotes become \", backslashes become \\, newlines become \n, tabs become \t, carriage returns become \r, and other control characters become \uXXXX. The result is a string you can safely paste as a value inside a JSON document, a REST request body, a configuration file, or a database column. Nothing is uploaded — the conversion runs 100% client-side, so it is safe for payloads containing PII, secrets, or internal data.
**Q: What is the difference between JSON escape and JSON stringify?**
A: They describe the same core operation from two angles. JSON.stringify() in JavaScript takes a value and produces its JSON text representation; when the value is a string, that means wrapping it in double quotes and escaping the special characters inside — which is exactly JSON escaping. This tool does precisely that: with Wrap in double quotes on, the output equals JSON.stringify(yourText); with it off, you get the escaped body without the surrounding quotes, which is what you need when you are building the JSON by hand and already typed the quotes. So if you searched for json stringify online, this is the tool — it gives you both the quoted and unquoted forms.
**Q: Is my data uploaded anywhere?**
A: No. All escaping runs entirely in your browser using JavaScript — your text is never transmitted, stored, logged, or analyzed on any server. This makes the tool safe for API payloads with PII, authentication tokens, internal configuration, and production secrets. You can verify it in your browser's Network tab: typing or pasting triggers zero network requests. There are no cookies for your input and no third-party analytics that capture what you paste.
**Q: When do I need the \uXXXX (escape non-ASCII) option?**
A: JSON allows raw UTF-8, so by default an é stays an é and an emoji stays an emoji — perfectly valid and more readable. Turn on Escape non-ASCII only when a downstream system cannot be trusted with UTF-8: old SOAP/XML gateways, some logging pipelines, email headers, or source files that must stay pure ASCII. With it on, every character above U+007F becomes a \uXXXX sequence (astral characters like emoji become a surrogate pair, e.g. 😀 → \ud83d\ude00). The escaped output is byte-for-byte ASCII and decodes back to the original Unicode in any compliant JSON parser.
**Q: How do I embed a JSON object inside another JSON string (JSON-in-JSON)?**
A: Paste the inner JSON into the input, keep Wrap in double quotes on, and copy the result — it is now a single escaped string you can assign to a key in the outer document. For example {"a":1} becomes "{\"a\":1}", which you place after a colon: {"payload": "{\"a\":1}"}. This double-encoding is common in webhook envelopes, message-queue payloads, and audit logs that store a request body as a string. To reverse it and read the inner object, use our JSON Unescape tool.
**Q: What does the Escape forward slash (\/) option do?**
A: The forward slash / is a normal character in JSON and does not require escaping, so it is left alone by default. The option exists for one specific case: embedding JSON inside an HTML <script> tag, where the sequence </script> would prematurely close the tag. Escaping / to \/ turns </script> into <\/script>, which is still valid JSON but no longer a tag terminator. Enable it only when you are inlining JSON into HTML; for every other use, leave it off for cleaner output.
**Q: Does it handle newlines, tabs, and control characters correctly?**
A: Yes. The tool is built on the JSON specification's exact escaping rules: newline → \n, carriage return → \r, tab → \t, backspace → \b, form feed → \f, double quote → \", backslash → \\, and any remaining control character below U+0020 → \uXXXX. This is identical to what a compliant JSON serializer produces, so the output round-trips losslessly: escape it here, parse it anywhere, and you get your original text back byte for byte.
---
### JSON Formatter & Validator
URL: https://go-tools.org/tools/json-formatter
Format, validate and beautify JSON instantly in your browser. Free online tool with syntax validation, error detection, minify and one-click copy. 100% private.
#### What is JSON?
JSON (JavaScript Object Notation) is a lightweight, text-based data interchange format that is easy for humans to read and write, and easy for machines to parse and generate. Standardized as RFC 8259 and ECMA-404, JSON has become the universal standard for data exchange across virtually all programming languages, APIs, and web services.
As Douglas Crockford, the creator of JSON, wrote on json.org: "JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript." This deliberate simplicity is exactly why JSON won out over XML and became the lingua franca of the modern web.
JSON supports six data types: strings (in double quotes), numbers, booleans (true/false), null, arrays (ordered lists), and objects (key-value pairs) (RFC 8259). Its simplicity and readability have made it the preferred format over XML for most modern web applications, REST APIs, and configuration files. JSON is the most popular data format for APIs, used by 86% of developers (Postman State of API Report 2023).
A JSON formatter transforms raw or minified JSON into a well-structured, indented format that makes the data hierarchy immediately visible. This is essential for debugging API responses, inspecting configuration files, and understanding complex nested data structures. Unlike XML, JSON does not support comments, attributes, or namespaces — it focuses purely on data representation (ECMA-404).
This tool runs entirely in your browser — your JSON data never leaves your device. Unlike server-based formatters, there are no uploads, no logging, and no data retention. Safe to use with API keys, production configs, and proprietary data.
JSON is frequently used with other developer tools. When debugging APIs, you may need to decode Base64-encoded JSON payloads (such as JWT tokens), or generate UUIDs for use as unique identifiers within JSON data structures. Working with JSON5 or JSONC config files? See our JSON5 and JSONC formatting guide for syntax differences, tooling support, and best practices. For a deep dive on YAML's Norway problem and JSON ↔ YAML conversion, read our YAML Norway problem & JSON-YAML differences guide, or convert directly with JSON to YAML and YAML to JSON. Need to compare two JSON documents and find what changed? Try our JSON Diff. To move tabular JSON into a spreadsheet or import a CSV export back into JSON, use JSON to CSV and CSV to JSON.
```
// Format (pretty-print) JSON with 2-space indentation
const raw = '{"name":"Alice","age":30,"active":true}';
const parsed = JSON.parse(raw); // parse string → object
const formatted = JSON.stringify(parsed, null, 2);
console.log(formatted);
// → {
// "name": "Alice",
// "age": 30,
// "active": true
// }
// Minify JSON (strip all whitespace)
const minified = JSON.stringify(parsed);
console.log(minified);
// → '{"name":"Alice","age":30,"active":true}'
```
#### FAQ
**Q: How do I format JSON online?**
A: Paste your raw or minified JSON into the input field above and click "Format JSON." The tool instantly parses your data, validates the syntax, and displays a properly indented version with 2-space indentation. You can then copy the result to your clipboard with one click. Everything runs locally in your browser — no data is sent to any server.
**Q: How do I validate JSON?**
A: Paste your JSON into the input field and click "Format JSON." If the JSON contains syntax errors, the tool displays a detailed error message showing what went wrong and where. If the JSON is valid, it will be formatted and displayed in the output area. This tool validates against RFC 8259, the current JSON standard.
**Q: How do I minify JSON?**
A: Paste your JSON into the input field and click "Minify JSON." The tool removes all unnecessary whitespace, line breaks, and indentation to produce the most compact representation. Minified JSON is ideal for API responses, configuration files in production, and anywhere file size or bandwidth matters.
**Q: Is my JSON data safe when using this tool?**
A: Yes, completely. All processing happens locally in your browser using JavaScript's native JSON.parse() and JSON.stringify() — your data never leaves your device. There are no server uploads, no cookies, no analytics tracking on your input, and no data storage of any kind. This makes it safe to use with API keys, credentials, and proprietary data.
**Q: How do I fix "Unexpected token" errors in JSON?**
A: An "Unexpected token" error means the JSON parser found a character that doesn't belong at that position. The most common causes are: a missing comma between elements ({"name": "Alice" "age": 30}), a trailing comma after the last element ({"name": "Alice",}), or extra characters after the JSON ends. Paste your JSON into this tool to see the exact error location, then check the characters around that position.
**Q: Why does my JSON have a "trailing comma" error?**
A: JSON does not allow a comma after the last element in an object or array. This is one of the most common errors because JavaScript and many other languages permit trailing commas. For example, {"name": "Alice", "age": 30,} is invalid JSON — remove the comma after 30 to fix it. If you frequently copy data from JavaScript code, always check for trailing commas before using it as JSON.
**Q: Can I use single quotes in JSON?**
A: No. JSON requires double quotes for all strings and property keys. Single quotes are valid in JavaScript and Python, but they are not part of the JSON specification (RFC 8259). For example, {'name': 'Alice'} is invalid — it must be {"name": "Alice"}. If you have data with single quotes, this tool will report a syntax error and show you the exact position to fix.
**Q: Can I add comments to JSON?**
A: No, standard JSON does not support comments of any kind — no //, /* */, or # syntax. This was an intentional design decision to keep JSON simple and parseable. If you need comments in configuration files, consider JSONC (JSON with Comments, used by VS Code and TypeScript), JSON5, or YAML. To use commented files as standard JSON, strip the comments before parsing.
**Q: Why is my JSON not parsing correctly?**
A: The most common reasons JSON fails to parse are: (1) trailing commas after the last element, (2) single quotes instead of double quotes, (3) unquoted property keys, (4) comments in the data, (5) missing or extra brackets/braces, (6) unescaped special characters like backslashes or newlines inside strings. Paste your JSON into this tool — it will pinpoint the exact error type and location so you can fix it quickly.
**Q: What is the difference between JSON and YAML?**
A: Both JSON and YAML are data serialization formats, but they differ in design philosophy. JSON uses braces, brackets, and double quotes with a strict syntax — making it ideal for machine parsing and APIs. YAML uses indentation and minimal punctuation — making it more human-readable and popular for configuration files (Docker Compose, Kubernetes, GitHub Actions). JSON is a subset of YAML, so any valid JSON is also valid YAML, but not vice versa.
**Q: What is JSON Schema?**
A: JSON Schema is a separate standard (not part of JSON itself) that defines the expected structure, types, and constraints of JSON data. For example, you can specify that a field must be a string, a number must be between 1 and 100, or an array must contain at least one element. JSON Schema is widely used for API request/response validation, form generation, and documentation. This tool validates JSON syntax, not JSON Schema — for schema validation, use a dedicated JSON Schema validator. For end-to-end validation patterns in Node, Python, and the browser, see our complete JSON Schema validation guide.
**Q: What is the difference between JSON and JSON5?**
A: JSON5 is an extension of JSON that adds features developers frequently request: single and double quotes, trailing commas, comments (// and /* */), unquoted keys, multiline strings, and hexadecimal numbers. JSON5 is often used in configuration files where human editing is common. Standard JSON parsers cannot read JSON5 — you need a JSON5 parser. This tool works with standard JSON (RFC 8259) only.
**Q: What is the maximum size of a JSON file?**
A: The JSON specification itself has no file size limit. Practical limits depend on the parser and environment: browsers typically handle JSON up to 500 MB–1 GB before running into memory issues, while server-side parsers (Node.js, Python, Java) can handle larger files with streaming parsers. This online tool efficiently handles JSON up to about 10 MB. For very large JSON files, consider using command-line tools like jq or streaming parsers.
**Q: I have a large API response that's completely minified — what's the fastest way to make it readable for debugging?**
A: Paste the minified JSON into this tool and click Format JSON. It will instantly parse and pretty-print the data with 2-space indentation, making nested objects and arrays immediately visible. For very large responses (5-10 MB), this browser-based tool is often faster than VS Code or command-line jq because it uses the browser's native JSON.parse() with zero startup overhead. You can also use the keyboard shortcut Ctrl+V to paste and the result appears instantly. For programmatic formatting, use JSON.stringify(data, null, 2) in JavaScript or python -m json.tool from the command line.
**Q: I keep getting JSON parse errors when copying data from my JavaScript code — what am I doing wrong?**
A: The most common cause is that JavaScript object literals are not valid JSON. Three key differences trip people up: (1) JavaScript allows single quotes ('name') but JSON requires double quotes ("name"); (2) JavaScript allows trailing commas ({"a": 1,}) but JSON does not; (3) JavaScript allows unquoted keys ({name: "Alice"}) but JSON requires quoted keys ({"name": "Alice"}). Additionally, JavaScript comments (// or /* */) are not valid in JSON. Paste your data into this tool — it will pinpoint the exact error type and position so you can fix it quickly. If you frequently need to convert JS objects to JSON, consider using JSON5 format as an intermediate step.
---
### JSON Schema Validator
URL: https://go-tools.org/tools/json-schema-validator
Validate JSON against any JSON Schema instantly in your browser. Supports Draft 2020-12, 2019-09, and Draft-07 with path-precise error messages. 100% private — no upload, no account, free.
#### What is a JSON Schema Validator?
A JSON Schema validator is a program that takes two JSON documents — a data document and a schema document — and reports whether the data conforms to the schema's contract. The schema declares field types, required keys, value ranges, allowed enum values, regex patterns, and structural rules using a fixed vocabulary (type, properties, required, items, enum, oneOf, allOf, $ref, format). The validator walks both documents in parallel and emits zero or more errors, each pinned to a JSON Pointer path inside the data.
Validation runs at runtime, at the boundary between untrusted input and your code. TypeScript types vanish at compile time and cannot help with JSON arriving from a webhook, a third-party API, or a user paste — that gap is exactly what JSON Schema fills. Pair it with TypeScript (or Pydantic in Python) and you get compile-time guarantees inside your codebase plus runtime guarantees at the boundary.
Draft 2020-12 is the current spec and what you should pick for new projects in 2026. Earlier drafts (2019-09, Draft-07, Draft-06, Draft-04) survive in legacy codebases — Draft-07 is still common in Helm charts, VS Code settings, and older Ajv configs. OpenAPI 3.1 uses Draft 2020-12 natively; OpenAPI 3.0 uses a Draft 4 subset.
This tool runs entirely in your browser. Your JSON, your schema, and the validation output never leave your machine — safe for proprietary API contracts and sensitive payloads. Internal $ref pointers resolve automatically; external HTTP refs are intentionally disabled to preserve privacy.
Working with adjacent JSON tools? Format the JSON with JSON Formatter before pasting; compare two JSON documents with JSON Diff; convert with JSON to YAML and YAML to JSON. For end-to-end validation in Node, Python, and the browser, see our JSON Schema validation guide.
```
// A 5-line schema that catches three real bugs
const schema = {
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"id": { "type": "integer", "minimum": 1 },
"email": { "type": "string", "format": "email" },
"age": { "type": "integer", "minimum": 0, "maximum": 150 }
},
"required": ["id", "email"],
"additionalProperties": false
};
// Three bugs the schema catches:
const bad = { "id": "42", "age": 200 };
// /id → type: expected integer, got string
// /email → required: missing
// /age → maximum: 200 > 150
// In Node: new Ajv().compile(schema)(bad) // false; ajv.errors has the paths
// In Python: jsonschema.validate(bad, schema)
// In the browser: this tool — same errors, same paths, no install
```
#### FAQ
**Q: What is JSON Schema validation?**
A: JSON Schema validation checks whether a JSON document matches a contract written in JSON Schema syntax. The schema declares field types, required keys, allowed values, and structural rules; the validator walks both documents in parallel and reports any path that violates the contract. It runs at the boundary between untrusted input (API request, webhook, config file, form payload) and your business logic — catching shape errors before they corrupt downstream code. See our complete guide to JSON Schema validation for end-to-end Node, Python, and browser examples.
**Q: Which JSON Schema drafts does this validator support?**
A: Draft 2020-12 (default and recommended), Draft 2019-09, and Draft-07. The validator auto-detects the draft from the schema's $schema URI when present and falls back to your selection from the dropdown otherwise. For new projects in 2026 use Draft 2020-12 — it is what OpenAPI 3.1 uses natively and what Ajv defaults to. Draft-07 remains common in legacy codebases (older AJV setups, Helm charts, VS Code settings).
**Q: How do I validate JSON against a schema?**
A: Paste your JSON data into the left panel and your JSON Schema into the right panel. The validator runs instantly as you type — green check means valid, red list means errors. Each error includes a JSON Pointer path (for example /user/email), the failing keyword (type, required, pattern, minimum), and a human-readable message. Click any error to jump to the offending line. No upload, no signup.
**Q: What's the difference between JSON Schema validation and JSON syntax validation?**
A: JSON syntax validation only confirms the document parses — no extra commas, no missing braces. JSON Formatter handles that. JSON Schema validation runs after parsing and checks whether the parsed structure matches the contract: required fields present, types correct, values within range. You typically run both — format first to confirm parseable, then validate against the schema.
**Q: Why is my schema rejecting JSON that looks correct?**
A: Five usual suspects: (1) additionalProperties: false — your data has a key the schema didn't declare, often a typo or a new field; (2) type: "integer" vs "number" — JSON Schema treats 1.0 as a number, not an integer; (3) format keywords (email, uri, uuid) reject malformed strings even when they look fine; (4) required at the wrong nesting level — required must appear next to properties, not inside one; (5) the JSON has a string "42" where the schema expects integer 42. The error path will pinpoint which one.
**Q: Does this support $ref and remote schema references?**
A: Internal $ref pointers (#/$defs/foo, #/properties/bar) work out of the box. Remote $ref to external URLs is intentionally disabled — fetching external schemas would leak your validation activity to third parties and break the privacy model. To validate against a multi-file schema, inline the referenced definitions into a single document using $defs, or run validation in your own CI with Ajv where remote refs are appropriate.
**Q: What does additionalProperties: false do?**
A: additionalProperties: false rejects any key that isn't declared in properties. It's the single most useful keyword for tightening contracts — without it, schemas are open by default and silently accept misspelled or malicious fields. Always set additionalProperties: false on input contracts (request bodies, config files, queue messages). Leave it true (or omit it) only when the schema is a partial description of a larger document.
**Q: How do I validate JSON against a schema in Node.js or Python?**
A: Node: install Ajv (npm i ajv ajv-formats), call new Ajv().compile(schema), then validate(data). Python: install jsonschema (pip install jsonschema), call jsonschema.validate(data, schema). For TypeScript, generate types from the schema using json-schema-to-typescript so compile-time and runtime stay in sync. Our JSON Schema validation guide has copy-paste recipes for Node, Python, and browser.
**Q: What's the difference between oneOf, anyOf, and allOf?**
A: allOf — must match every subschema (intersection, used for composition). anyOf — must match at least one (union, fast-fail). oneOf — must match exactly one (discriminated union, slower but stricter). Use oneOf for discriminated unions like webhook events tagged by type; use anyOf for permissive unions; use allOf to extend a base schema with extra constraints. oneOf is the slowest because it tests every branch — prefer anyOf when exactly-one isn't required.
**Q: Does it support OpenAPI schemas?**
A: OpenAPI 3.1 uses Draft 2020-12 natively, so any OpenAPI 3.1 schema component pastes in directly. OpenAPI 3.0 uses a Draft 4 subset that's mostly compatible — you may hit edge cases around nullable: true (3.0 syntax) which Draft 2020-12 expresses as type: ["string", "null"]. For full OpenAPI document validation (paths, operations, security), use a dedicated OpenAPI linter like Spectral; this tool focuses on the schema portion.
**Q: Why does the validator say my JSON Schema is itself invalid?**
A: JSON Schema is a JSON document that must be valid JSON before it can be a valid schema. Common causes: trailing comma in a properties object, single quotes instead of double, $schema set to a non-existent draft URL, or required listed as a string instead of an array. Format the schema in JSON Formatter first to surface syntax issues, then paste it back here for semantic validation.
**Q: Does the tool send my JSON or schema to a server?**
A: No. All parsing and validation runs locally in your browser. Your JSON, your schema, and the validation results never leave your machine — no upload, no localStorage of inputs, no analytics on what you paste. Safe for proprietary API contracts, internal config files, and sensitive payloads. Only your draft selection persists in localStorage so it survives a refresh; clear browser data to wipe it.
**Q: Can I validate JSON Lines (NDJSON) or multiple documents?**
A: This tool validates one document per run. For JSON Lines, validate each line individually or use Ajv in Node with a schema and a stream parser like JSONStream. For batch validation of large datasets, prefer the command-line — ajv-cli or check-jsonschema (Python) handle thousands of files per second with a single schema compile.
---
### JSON to CSV Converter
URL: https://go-tools.org/tools/json-to-csv
Convert JSON to CSV in your browser. RFC 4180, Excel-EU, TSV, Pipe presets. Flatten nested or stringify. 100% private, no upload.
#### What is CSV and Why Convert from JSON?
CSV (Comma-Separated Values) is the oldest and most widely supported tabular data format in computing — every spreadsheet app, every database, every analytics tool, and most programming languages have first-class CSV support. JSON, by contrast, is the universal format for API responses, configuration, and structured data exchange. Converting between them is one of the most common chores in data engineering: you receive JSON from an API or a NoSQL database, and you need a CSV to load into Excel for analysis, into a Postgres table via COPY, or into a BigQuery / Snowflake warehouse. This tool is built for that conversion path and handles four scenarios that most online converters botch.
This tool has four important differentiators compared to typical online converters:
**1. RFC 4180 State-Machine Parser.** CSV looks simple but the quoting rules are subtle: a field wrapped in double quotes can contain commas, embedded newlines, and escaped double quotes (doubled, like ""). Naive split-by-comma parsers break on real-world data — addresses with commas, multiline text fields, and quoted values containing quotes. This tool implements a proper state-machine parser following RFC 4180 (the IETF spec for CSV), correctly handling quoted fields, embedded delimiters, embedded line endings, and escaped quotes in every direction. The output is round-trippable through Python's csv module, PostgreSQL COPY, AWS S3 SELECT, and any compliant parser.
**2. Flatten One-Way / Stringify Reversible.** Nested JSON is fundamentally incompatible with CSV's flat tabular shape, and most converters silently corrupt data when they hit a nested object or array. This tool gives you an explicit choice: Flatten mode emits dotted keys (customer.address.city) and indexed keys (items.0.sku) for the cleanest spreadsheet layout — readable in Excel but lossy for round-trips. Stringify mode keeps arrays and objects as JSON inside a single cell — uglier but fully round-trippable: CSV → JSON → CSV produces identical data when paired with Infer types on the reverse. Choose based on your goal: analysis in Excel (Flatten) or pipeline round-trips (Stringify).
**3. Big-Integer Detection.** JavaScript's Number type uses IEEE 754 double precision and silently rounds integers above 2^53 - 1 (9007199254740991). This bites real-world JSON: Twitter snowflake IDs, Discord IDs, MongoDB Long fields, and Kubernetes resourceVersion are all 64-bit integers that exceed the safe range. Most browser-based JSON tools silently produce wrong numbers without warning. This tool detects big-integer values during parsing, shows a warning banner listing affected fields, and preserves the original digits as strings in the CSV output so Excel and Google Sheets won't truncate them to scientific notation.
**4. 100% Browser-Based Privacy.** Your JSON data — which often contains user PII, internal database exports, API keys embedded in payloads, and production secrets — never leaves your browser. No data is sent to any server, no logging, no analytics that capture input. You can verify this in your browser's Network tab. This is the only safe way to handle sensitive data in an online tool. See the reverse direction by clicking Swap or use our companion JSON to YAML Converter when YAML is your target. Need to validate JSON before converting? Try our JSON Formatter.
CSV's strengths are universality and simplicity: every tool reads it, parsers are tiny, and the file format is human-readable in any text editor. Its weaknesses are the lack of type information (everything is a string until you tell the parser otherwise), no native nested-structure support, and locale-specific quirks (Excel-EU semicolons, Windows CRLF vs Unix LF). JSON's strengths are exactly the opposite: precise types, native nesting, and a strict spec that parses identically everywhere. The right tool depends on the consumer: human reading a spreadsheet → CSV, machine consuming an API → JSON. This converter handles the bridge in both directions.
```
// Input JSON
[
{ "id": 1, "name": "Alice", "role": "admin" },
{ "id": 2, "name": "Bob", "role": "editor" }
]
// Output CSV (RFC 4180 preset: comma + CRLF + no BOM)
id,name,role
1,Alice,admin
2,Bob,editor
// Same input with Stringify mode + nested data
[
{ "id": 1, "tags": ["a", "b"] }
]
// Becomes
id,tags
1,"[""a"",""b""]"
```
#### FAQ
**Q: What does this tool do?**
A: It converts JSON to CSV directly in your browser, with bidirectional support: click Swap direction to convert CSV back to JSON in the same panel. Paste JSON in the input area and the tool produces CSV output instantly — no upload, no signup, nothing leaves your machine. The output respects your chosen preset (RFC 4180, Excel, TSV, or Pipe) so you can paste straight into Excel, Google Sheets, a database COPY command, or any data pipeline. The tool handles flat arrays of objects, nested structures (via Flatten or Stringify mode), NDJSON line-delimited input, and big-integer values that would otherwise lose precision in spreadsheet apps.
**Q: Is my data uploaded anywhere?**
A: No. All conversion runs 100% client-side in your browser using JavaScript. Your JSON data is never transmitted, never stored on any server, never logged, and never analyzed. This makes the tool safe for API responses containing PII, internal database exports, MongoDB dumps, and any sensitive data. You can verify this in your browser's Network tab — pasting JSON triggers zero network requests. The tool uses no cookies for input data and no third-party analytics that would capture what you paste.
**Q: What's the difference between Flatten and Stringify mode?**
A: Flatten mode emits dotted keys for nested objects and indexed keys for nested arrays (customer.address.city, items.0.sku) so each leaf value lives in its own column. This is the most readable layout for analysis in Excel or BigQuery, but it is lossy for round-trips because the dotted-key structure cannot be perfectly reconstructed. Stringify mode keeps arrays and objects as JSON inside a single cell ({"name":"Alice","city":"Seattle"}) — uglier in a spreadsheet, but fully round-trippable: CSV → JSON → CSV produces identical data. Choose Flatten for analysis, Stringify for round-trip safety. Pick before you convert; switching mid-session re-runs the conversion on the current input.
**Q: How does it handle big integers like Twitter IDs or Snowflake keys?**
A: Big integers (above 2^53 - 1, or 9007199254740991) are detected during JSON parsing and a warning banner appears below the output. The tool preserves the original digits as strings in the CSV so Excel and Google Sheets won't truncate them to scientific notation. This matters because JavaScript's IEEE 754 double-precision float silently rounds integers above 2^53 — for example, 9007199254740993 becomes 9007199254740992. To preserve precision when generating the JSON upstream, store these IDs as strings ("id": "9007199254740993"). The tool will keep them as strings in the CSV without any precision loss.
**Q: Why is Excel showing my CSV in one column?**
A: European Excel locales (Germany, France, Spain, Italy, etc.) expect a semicolon delimiter because the comma is reserved for decimal separators. When you open a comma-delimited CSV in Excel-EU, every row collapses into column A. Use the Excel preset on this tool — it switches the delimiter to ;, the line ending to CRLF, and adds a UTF-8 BOM so Excel correctly detects encoding and column boundaries. If you are sharing CSVs across regions, the safer option is TSV (Tab delimiter) which Excel handles consistently in every locale.
**Q: Does this support NDJSON or JSON Lines?**
A: Yes. NDJSON (.ndjson) and JSONL (.jsonl) are line-delimited formats where each line is one valid JSON value. Paste the file contents directly into the input area — the tool auto-detects the format by looking for multiple top-level JSON values separated by newlines, and treats each line as a row in the output CSV. This is the natural shape for streaming logs, API event exports, and many data lake pipelines. NDJSON does not require a wrapping array, so you do not need to manually merge lines into one JSON document.
**Q: What is RFC 4180?**
A: RFC 4180 is the IETF specification that codified the de facto CSV format in 2005. It defines the rules for delimiters (typically comma), line endings (CRLF), the optional header row, and most importantly the quoting rules: fields containing the delimiter, double quote, CR, or LF must be wrapped in double quotes, and embedded double quotes are escaped by doubling them (""). The RFC 4180 preset on this tool produces output strictly compliant with the spec: comma delimiter, CRLF line endings, no BOM, double-quote auto-escaping. This is the safest choice for interoperability with parsers in Python (csv module), PostgreSQL COPY, AWS S3 SELECT, and most data pipelines.
**Q: Why are some cells wrapped in quotes and others not?**
A: The default Quote mode is Auto, which follows RFC 4180: a cell is wrapped in double quotes only when it contains the delimiter, a double quote, a carriage return, or a newline. This produces the cleanest, most human-readable CSV — values like Alice or 42 stay unquoted, while values like Smith, Jr. or Line 1\nLine 2 get wrapped. Switch to Always quote mode to wrap every cell, even simple ones — useful when downstream tools have buggy CSV parsers that misinterpret unquoted values, or when your team's pipeline expects every field to be quoted for consistency.
**Q: Can I round-trip CSV → JSON → CSV without data loss?**
A: Yes, when the input is flat (no nested objects or arrays). For nested data, you must use Stringify mode — it keeps arrays and objects as JSON inside a single cell, which round-trips losslessly back to the original structure when you reverse with Swap direction and Infer types. Flatten mode is one-way: it emits dotted keys (customer.address.city) that cannot be perfectly reconstructed because the parser cannot distinguish a dotted key from a nested path. The tool detects nested structures and shows a Schema notes warning when round-trip safety is at risk so you can switch modes before exporting.
**Q: How do I get a TSV file?**
A: Click the TSV preset chip. This switches the delimiter to Tab, the line ending to LF, and disables the BOM — the standard format for tab-separated values used by Unix tools (cut, awk), data warehouses (BigQuery, Snowflake), and most Excel locales without ambiguity. TSV is generally safer than comma-CSV for cross-locale sharing because Tab is unlikely to appear inside text fields, eliminating most quoting edge cases. Save the output with a .tsv or .tab extension and most tools will recognize it automatically.
**Q: What happens with very large input?**
A: Above 100,000 characters or 2,000 rows, live conversion automatically switches to manual mode: a Convert button appears in an info banner and conversion only runs when you click it. This prevents the browser's main thread from blocking on every keystroke during heavy serialization. For output above 5 MB or 50,000 rows, the tool truncates the on-screen preview to the first 500 rows and shows a Showing the first 500 of N rows banner — but the Download button still produces the full file with every row included. Hard upper limit is 10 MB of input; above that the tool shows an error and asks you to reduce the input.
**Q: What encodings are supported?**
A: Input and output are both UTF-8. UTF-8 covers every modern character set including emoji, CJK ideographs, Arabic, Hebrew, and combining marks. The only encoding nuance is the optional UTF-8 BOM (Byte Order Mark): Excel on Windows traditionally needs the BOM to detect UTF-8 correctly, otherwise it falls back to the system locale and mangles non-ASCII characters. Toggle BOM on (or use the Excel preset, which enables BOM by default) when you plan to open the CSV in Excel. Leave BOM off for everything else — most modern parsers (PostgreSQL, Pandas, jq, Python csv) will choke or include the BOM as a stray character at the start of the first cell.
---
### JSON to .env Converter
URL: https://go-tools.org/tools/json-to-env
Paste a JSON object, get a .env file instantly. Generate dotenv from config locally — your keys and secrets never leave your browser. 100% private, no upload.
#### What is a .env File and Why Generate One from JSON?
A .env file (dotenv file) is a plain-text list of KEY=VALUE pairs that holds environment configuration and secrets outside your source code. It is the de facto standard for Node.js, Vite, Next.js, Python, Ruby and Docker Compose — the dotenv library loads the file and injects each pair into the process environment. Because it commonly stores database passwords, API keys and access tokens, a .env file is treated as sensitive and kept out of version control.
Generating a .env file from JSON is the reverse of the common parse-config task: you already have configuration as a JSON object — from an API response, a config export, a secrets-manager dump, or a script that builds settings programmatically — and you need a .env file to drop into a project or hand to a container. This converter walks the top-level keys of your JSON object and writes one correctly quoted KEY=VALUE line per property.
This tool is built around a few deliberate decisions:
**1. Round-trip-safe quoting.** Numbers and booleans are written bare, null becomes an empty value, and any string that contains a space, newline, # or quote is automatically double-quoted and escaped. The result parses back cleanly through dotenv and through the companion .env to JSON Converter, so a value never changes meaning on the round trip.
**2. Honest handling of nesting.** A .env file is flat by definition. Rather than silently dropping nested data, the tool serializes each nested object or array to a compact JSON string and warns you which keys were flattened, so you can decide whether .env is really the right target.
**3. Optional key normalization.** Keys are kept verbatim by default to avoid losing information. Turn on Normalize keys to convert camelCase or kebab-case into the UPPER_SNAKE_CASE convention environment variables use, with a warning for any key that still cannot form a valid name.
**4. 100% browser-based privacy.** The JSON you paste — usually the very credentials you are about to write into a .env — never leaves the browser. No upload, no server round-trip, no logging; verify zero network requests in the DevTools Network tab.
Before converting, you can validate or pretty-print the JSON with the JSON Formatter, or unescape a JSON string with JSON Escape. If your configuration is better expressed with structure, JSON to YAML preserves nesting that a flat .env cannot.
```
// Generate .env lines from a JSON object in Node.js
const config = {
DATABASE_URL: 'postgres://user:pass@localhost:5432/mydb',
PORT: 8080,
DEBUG: true,
NOTE: 'value with spaces',
};
const needsQuotes = (s) => /[\s#"'\n]/.test(s);
const env = Object.entries(config)
.map(([key, value]) => {
if (typeof value === 'string') {
return needsQuotes(value)
? `${key}=${JSON.stringify(value)}`
: `${key}=${value}`;
}
return `${key}=${value ?? ''}`; // null -> empty value
})
.join('\n');
console.log(env);
// DATABASE_URL=postgres://user:pass@localhost:5432/mydb
// PORT=8080
// DEBUG=true
// NOTE="value with spaces"
```
#### FAQ
**Q: How do I convert JSON to a .env file online?**
A: Paste a JSON object into the input field above. The tool generates a .env file instantly in your browser — no button click needed. Each top-level property becomes a KEY=VALUE line. You can optionally normalize keys to UPPER_SNAKE_CASE or add an export prefix from the Options panel, then click Copy to grab the result or Download to save it as a .env file. Everything runs locally, so your secrets never leave your device.
**Q: What kind of JSON does this accept?**
A: The input must be a JSON object (a set of key/value pairs at the top level), because a .env file is fundamentally a flat list of variables. A top-level array or a bare scalar like a string or number cannot map to environment variables, so the tool reports an error asking for an object. Invalid JSON also produces an error with best-effort line and column numbers so you can locate the problem quickly.
**Q: How are strings, numbers, booleans and null written?**
A: Numbers and booleans are written without quotes (PORT=8080, DEBUG=true). A null value becomes an empty assignment (KEY=), which dotenv loads as an empty string. Plain strings are written as-is, but a string containing spaces, a newline, a #, or a quote character is automatically wrapped in double quotes and escaped so it parses back correctly. This means the output round-trips cleanly through the dotenv parser and through our companion .env to JSON Converter.
**Q: What happens to nested objects and arrays?**
A: .env files cannot represent nesting — every variable is a flat string. When a value is a nested object or array, the tool serializes it to a compact JSON string with JSON.stringify, wraps it in double quotes, and escapes it. A non-blocking warning lists exactly which keys were flattened this way, so you always know the structure was collapsed. If your data is deeply nested, a format like JSON to YAML preserves the hierarchy far better than .env can.
**Q: What does the Normalize keys option do?**
A: By default the original JSON keys are kept exactly as written, so no data is lost — and in that mode any key that is not already a valid environment variable name (most shells and loaders only accept names matching [A-Za-z_][A-Za-z0-9_]*) is flagged with a warning so you can rename it. With Normalize keys enabled, keys are converted to UPPER_SNAKE_CASE — the conventional style for environment variables (databaseUrl becomes DATABASE_URL, enable-signup becomes ENABLE_SIGNUP) — which resolves most invalid names automatically.
**Q: Is my JSON data sent to a server?**
A: No. All conversion happens entirely in your browser with JavaScript. The JSON you paste — which often holds API keys, database credentials and tokens you are about to write into a .env file — is never transmitted, never stored on any server, and never logged. You can confirm this by opening your browser's Network tab and watching that pasting triggers zero requests. That is what makes it safe to generate a real production .env, not just a sample.
---
### JSON to Python Class Converter
URL: https://go-tools.org/tools/json-to-python
Paste JSON, get Python classes instantly — dataclass, Pydantic v2, or TypedDict. Correct Optional typing, camelCase aliases, nested classes. 100% in your browser, free.
#### What is JSON to Python conversion?
JSON to Python conversion turns a JSON sample into ready-to-use Python classes — a standard-library dataclass, a Pydantic v2 model, or a TypedDict — so you never hand-write field definitions for an API response or config file. This Python class generator infers correct types (int, float, str, bool, Optional), turns nested objects into named classes, and adds Pydantic aliases for camelCase keys, all 100% in your browser.
#### FAQ
**Q: How do I convert JSON to a Python class?**
A: Paste your JSON into the input box. The converter parses it instantly in your browser and generates Python on the right. Pick dataclass, Pydantic v2, or TypedDict with the toggle, then click Copy — no upload, no account, no waiting.
**Q: What is the difference between dataclass, Pydantic, and TypedDict output?**
A: dataclass gives you a standard-library @dataclass with no dependencies — great for plain data holders. Pydantic v2 emits BaseModel classes that validate and coerce data at runtime, ideal for parsing untrusted API responses. TypedDict describes the shape of a plain dict for static type checkers (mypy, Pyright) with zero runtime cost. Switch modes to compare the same JSON in each.
**Q: How do I generate a Pydantic model from JSON?**
A: Choose the Pydantic v2 tab. Fields are converted to snake_case with Field(alias="originalKey") so the model still reads camelCase JSON, and model_config = ConfigDict(populate_by_name=True) lets you construct it by field name too. Parse a payload with Root.model_validate(data) — Pydantic validates types and raises a clear error on bad input.
**Q: How does the dataclass output handle camelCase keys?**
A: A dataclass has no built-in alias, so to keep Root(**data) working, dataclass mode keeps the original key as the field name when it is a valid Python identifier (publicRepos stays publicRepos). If you want idiomatic snake_case with aliases, use the Pydantic v2 mode instead, which maps snake_case fields back to the exact JSON key.
**Q: How are optional and null fields typed?**
A: When a key appears in some array items but not others, its type is wrapped in Optional. A field that is only ever null becomes Optional[Any], because JSON null alone carries no type. Paste a representative sample with a filled-in value to get a more specific type than Any.
**Q: What Python type does each JSON value map to?**
A: Strings map to str, booleans to bool, whole numbers to int, and any number with a decimal point or exponent to float. Because Python integers are arbitrary precision, even huge IDs stay int — there is no 64-bit overflow. Empty or mixed-type arrays become List[Any], and objects become nested classes.
**Q: Does it handle nested objects and arrays of objects?**
A: Yes. Each nested object becomes its own named class, and identical shapes are deduplicated into a single class reused by every field. Arrays of objects are merged key by key so you get one element class, with keys missing from some items marked Optional. Child classes are always emitted before the classes that use them.
**Q: How are Python keywords and non-identifier keys handled?**
A: A JSON key that is a Python keyword (class, from, import) gets a trailing underscore (class_). Keys with hyphens, spaces, or a leading digit are sanitized to valid identifiers in dataclass and Pydantic modes. In TypedDict mode, any dict containing a non-identifier key is emitted with the functional TypedDict('Name', {...}) syntax so the exact key like "first-name" is preserved.
**Q: How do I use the generated dataclass to parse JSON?**
A: For a flat object, json.loads then Root(**data) works directly. For nested structures, dataclass does not recurse automatically — either build the child objects yourself, use a library like dacite or pydantic.dataclasses, or switch this tool to Pydantic v2 mode, where Root.model_validate(json.loads(text)) parses the whole tree in one call.
**Q: Is my JSON data private and safe?**
A: Yes. Conversion runs 100% in your browser with JavaScript. Your JSON — including tokens, IDs, or customer data — never leaves the page and is never sent to a server.
**Q: Is the tool free? Do I need an account?**
A: It is completely free with no sign-up, no limits, and no ads cluttering the workspace. It works offline once the page has loaded.
---
### JSON to Rust Struct Converter
URL: https://go-tools.org/tools/json-to-rust
Paste JSON, get idiomatic Rust serde structs instantly, 100% in your browser. Correct i64/u64/f64 typing, Option for nulls, #[serde(rename)] for camelCase. Free.
#### What is JSON to Rust conversion?
JSON to Rust conversion turns a JSON sample into ready-to-compile Rust structs with serde's #[derive(Serialize, Deserialize)] macros, so you never hand-write deserialization boilerplate for API responses or config files. This fast Rust struct generator infers correct number types, marks absent fields as Option, and adds #[serde(rename)] for non-snake_case keys — all 100% in your browser.
#### FAQ
**Q: How do I convert JSON to a Rust struct?**
A: Paste your JSON into the input box. The converter parses it instantly in your browser and generates Rust structs with serde derives on the right. Click Copy to grab the result — no upload, no account, no waiting.
**Q: Does it generate serde derives? Do I need serde and serde_json?**
A: Yes — output uses #[derive(Debug, Clone, Serialize, Deserialize)] by default. Add serde with the derive feature to your Cargo.toml. You only need serde_json as a dependency if the output contains serde_json::Value, which appears for empty or mixed arrays and null-only fields. Turn off the serde toggle to emit plain structs.
**Q: How do I use the generated struct to parse JSON?**
A: Add serde_json to your Cargo.toml, then deserialize in one line: let root: Root = serde_json::from_str(json)?;. The generated Deserialize derive does the rest — use serde_json::from_slice for a byte slice or from_reader for a file or HTTP body, and serde_json::to_string to serialize back.
**Q: How are optional and null fields handled?**
A: When a key appears in some array items but not others, it becomes an Option field. A field that is only ever null becomes an optional serde_json::Value. serde treats Option as optional automatically, so no #[serde(default)] attribute is added or required.
**Q: How does it handle camelCase keys and Rust keywords?**
A: Field names are converted to idiomatic snake_case, and a #[serde(rename)] attribute maps them back to the exact JSON key. Reserved keywords like type or match are emitted as type_ or match_ with a rename, which is more robust than raw identifiers because it also covers self, crate, and super.
**Q: Can it use #[serde(rename_all)] instead of per-field renames?**
A: The tool emits a per-field #[serde(rename)] because it always works — even when one payload mixes camelCase, snake_case, and irregular keys. If every field in a struct shares one convention, delete those attributes and put a single #[serde(rename_all = "camelCase")] on the struct instead; both deserialize identically.
**Q: What Rust number type does it use?**
A: Integers map to i64, or u64 when a value exceeds i64::MAX, and fall back to f64 beyond u64 — so large IDs still round-trip. Any number written with a decimal point or exponent (like 1.0 or 2e3) maps to f64, because serde would reject a float into an integer field.
**Q: How are dates and timestamps typed?**
A: JSON has no date type, so ISO strings like 2011-01-25 or RFC 3339 timestamps come out as String. For real date handling, change the field to a chrono type — DateTime in the Utc time zone, or NaiveDate — and enable chrono's serde feature. serde then parses RFC 3339 automatically.
**Q: How do I handle objects with dynamic or unknown keys?**
A: When keys vary — for example a map of IDs to values — replace the generated struct with a HashMap keyed by String. To keep a typed struct but still capture extra fields, add a #[serde(flatten)] field that is a HashMap. For fully dynamic values, serde_json::Value is the catch-all type.
**Q: Is my JSON data private and safe?**
A: Yes. Conversion runs 100% in your browser with JavaScript. Your JSON — including tokens, IDs, or customer data — never leaves the page and is never sent to a server.
**Q: Can I generate plain Rust structs without serde?**
A: Yes. Turn off the serde toggle to drop the use serde line, the Serialize and Deserialize derives, and all #[serde(rename)] attributes — leaving clean structs. You can also toggle Debug and Clone derives and pub visibility.
**Q: Is the tool free? Do I need an account?**
A: It is completely free with no sign-up, no limits, and no ads cluttering the workspace.
---
### JSON to TOML Converter
URL: https://go-tools.org/tools/json-to-toml
Paste JSON, get TOML instantly in your browser. Safe null handling, top-level table checks, Cargo.toml & pyproject.toml-ready output. 100% private, no upload.
#### What is TOML and Why Convert from JSON?
TOML (Tom's Obvious, Minimal Language) is a configuration file format built to be unambiguous and easy for humans to read and edit. It is the standard config format for the Rust ecosystem (Cargo.toml), modern Python packaging (pyproject.toml), and tools like Hugo, Netlify, Poetry, and Foundry. JSON is the universal machine format that tools and APIs produce. Converting JSON to TOML is common when you have structured data as JSON but need a human-editable TOML config as the destination — generating a Cargo.toml or pyproject.toml, or turning an application's JSON settings into a readable config file.
TOML is more structured than JSON, and this tool turns that strictness into guidance rather than cryptic failures:
**1. Top-level table enforcement.** Every TOML document is a table at the root — a bare array or scalar is not valid TOML. Instead of emitting broken output for { top-level array } input, this tool detects it and tells you exactly how to wrap your data under a key, so you always get valid TOML or a clear explanation.
**2. Safe, transparent null handling.** JSON has null; TOML does not. Most converters either crash or silently discard data. This tool is explicit: object keys with null values are dropped and the removed keys are listed in a warning, and a null inside an array — which has no valid TOML representation — produces a precise, path-pointing error. You are never surprised by missing data.
**3. Idiomatic TOML output.** Nested objects become [tables], deeply nested objects become dotted tables ([tool.ruff]), and arrays of objects become arrays of tables ([[section]]) — the shape real Cargo.toml and pyproject.toml files use. The conversion is powered by the zero-dependency, TOML 1.0.0-compliant smol-toml library.
**4. 100% browser-based privacy.** Your JSON — which may contain credentials, tokens, or internal service details — never leaves your browser. No upload, no server, no logging. Confirm it in your browser's Network tab.
Need the reverse? Use the TOML to JSON Converter. Working with other config formats? Try the JSON to YAML Converter and YAML to JSON Converter, or clean up your JSON input first with the JSON Formatter. Each format has its niche: JSON for machine interchange, TOML for human-edited application and tooling config, and YAML for deeply nested infrastructure manifests. This converter lets you move from JSON to TOML without writing any code.
```
// Convert JSON to TOML in Node.js using the smol-toml library
import { stringify } from 'smol-toml';
const data = JSON.parse(`{
"package": { "name": "my-app", "version": "1.0.0" },
"dependencies": { "serde": { "version": "1.0" } }
}`);
// The top-level value must be an object; null values on objects are dropped.
const toml = stringify(data);
console.log(toml);
// [package]
// name = "my-app"
// version = "1.0.0"
//
// [dependencies.serde]
// version = "1.0"
```
#### FAQ
**Q: How do I convert JSON to TOML online?**
A: Paste your JSON into the input field above. The tool parses it and produces TOML instantly in your browser — no button click needed. Once the TOML appears in the output area, click Copy to grab it to your clipboard or Download to save it as a .toml file. Everything runs locally, so your JSON never leaves your device. Two things to know before you start: your JSON's top level must be an object (not an array), and null values have no TOML equivalent — the tool explains both clearly if they come up.
**Q: What is TOML and why convert JSON to it?**
A: TOML (Tom's Obvious, Minimal Language) is a configuration format designed to be easy for humans to read and write, with unambiguous semantics. It is the config format for Rust's Cargo, Python's pyproject.toml, Hugo, Netlify, Poetry, and more. You convert JSON to TOML when a tool or API gives you JSON but the destination expects TOML — for example, generating a Cargo.toml or pyproject.toml from structured data, or turning an application's JSON settings into a human-editable TOML config file.
**Q: Why must the top level of my JSON be an object?**
A: TOML documents are always a table (a set of key-value pairs) at the root — the specification does not allow a bare array, string, or number at the top level. So a JSON array like [1, 2, 3] or a lone value like 42 cannot be converted directly. The fix is to wrap it under a key: { "items": [1, 2, 3] } converts cleanly to items = [1, 2, 3]. This tool detects a non-object top level and tells you exactly how to wrap it, instead of producing broken output.
**Q: What happens to null values when converting JSON to TOML?**
A: TOML has no null type, so null cannot be represented. This tool handles it safely and transparently in two ways. When a null appears as an object value, TOML simply omits that key — and the tool shows a warning listing exactly which keys were dropped, so you are never surprised by silent data loss. When a null appears inside an array, there is no valid TOML output at all (an array cannot hold a gap), so the tool reports an error pointing at the exact path of the offending null. Either way, you know precisely what happened and where.
**Q: How are nested objects and arrays converted to TOML?**
A: A nested JSON object becomes a TOML table: { "owner": { "name": "Tom" } } becomes [owner] with name = "Tom". Deeply nested objects become dotted tables like [tool.ruff]. An array of objects becomes an array of tables written with double brackets ([[servers]]), which is the idiomatic TOML way to express repeated sections. Arrays of scalars stay inline as arrays (ports = [8001, 8002]). The output follows the TOML 1.0.0 specification.
**Q: What happens to floating-point numbers like 1.0?**
A: TOML distinguishes integers from floats, and a float whose fractional part is zero (like 1.0) is written as the integer 1. So { "version": 1.0 } becomes version = 1. The tool shows a small warning when this coercion happens, because it changes the value's type on a round-trip. If you need the value to stay a float, that distinction cannot be preserved through TOML for whole numbers — consider whether an integer is actually what you want.
**Q: Is my JSON data sent to any server?**
A: No. All parsing and conversion happen entirely in your browser using JavaScript. Your JSON is never uploaded, never stored, and never logged. This makes the tool safe for configuration that contains API keys, database credentials, or internal service details. You can verify this by opening your browser's Network tab — pasting JSON triggers zero network requests.
**Q: Can I convert TOML back to JSON?**
A: Yes. Use the companion TOML to JSON Converter for the reverse direction, or click the Swap direction button at the top of this tool to flip the input and output in place. TOML to JSON has fewer constraints — it accepts any valid TOML — so round-tripping JSON → TOML → JSON is reliable as long as your JSON had no nulls or top-level array to begin with.
**Q: How do I convert JSON to TOML on the command line?**
A: A popular option is the Go tool 'yj' (yj -jt reads JSON and writes TOML). In Python you can use the third-party 'tomli-w' package: import json, tomli_w; tomli_w.dump(json.load(open('config.json')), open('config.toml','wb')). In Node.js: import { stringify } from 'smol-toml'; const toml = stringify(JSON.parse(text)) — the same library this tool uses. For a quick one-off without installing anything, this browser tool is the fastest path.
**Q: How do I convert JSON to TOML in Python, Rust, or Node.js?**
A: In Python: import json, tomli_w; tomli_w.dump(json.load(open('config.json')), open('config.toml','wb')). In Rust: use serde_json and toml — let value: serde_json::Value = serde_json::from_str(&text)?; let toml = toml::to_string_pretty(&value)?. In Node.js: import { stringify } from 'smol-toml'; const toml = stringify(JSON.parse(text)) — this is exactly the approach used by this tool. Remember that the top-level value must be an object in all of these.
**Q: Does the converter preserve key order?**
A: Keys within a table are preserved in their original order, but TOML structure requires that all plain key-value pairs of a table come before any child table headers. So top-level scalars are emitted first, then tables and arrays of tables — the converter reorders only where the TOML grammar demands it. The data is identical; only the textual ordering of table sections shifts to produce valid TOML.
**Q: Is there a file size limit for JSON input?**
A: There is no hard limit, but inputs over 200KB switch from live conversion to manual mode: a Convert button appears and conversion runs only when you click it, keeping the browser responsive. Typical configuration payloads convert in well under 50 milliseconds.
---
### JSON to TypeScript Converter
URL: https://go-tools.org/tools/json-to-typescript
Paste JSON, get TypeScript interfaces instantly. 100% in your browser — data never leaves the page. interface or type, nested objects, arrays, optional fields. Free, no sign-up.
#### What is JSON to TypeScript conversion?
JSON to TypeScript conversion reads a JSON value and generates matching TypeScript interface or type definitions — eliminating hand-written boilerplate for API responses and config files. Paste a payload and get production-ready types in seconds, fully typed for nested objects, arrays, and optional fields.
#### FAQ
**Q: How do I convert JSON to a TypeScript interface?**
A: Paste your JSON into the input box. The converter reads it instantly in your browser and generates a TypeScript interface on the right. Click Copy to grab the result — no upload, no account.
**Q: Should I use `type` or `interface` for JSON data?**
A: Both work. `interface` is conventional for object shapes and gives slightly better editor errors; `type` is handy for unions and intersections. Use the Output toggle to switch between them and keep whichever your codebase prefers.
**Q: How are nested objects and arrays handled?**
A: Nested objects become separate, named interfaces (e.g. an `address` field yields an `Address` interface). Arrays of objects are merged into one element interface; primitive arrays become typed arrays like `string[]`.
**Q: How are optional and null fields handled?**
A: When a key is present in some array items but not others, it is marked optional. Choose `?:` (optional) or `| null` (explicit nullable) with the Optional fields toggle. Literal null values are typed as `null`.
**Q: How do I generate TypeScript types from JSON automatically in VSCode?**
A: You can install an extension, but you don't have to. This tool runs entirely in your browser — paste, copy, done — with no plugin to install, configure, or keep updated.
**Q: Is my JSON data private and safe?**
A: Yes. Conversion happens 100% in your browser using JavaScript. Your JSON — including any tokens, IDs, or customer data — never leaves the page and is never sent to a server.
**Q: Is the tool free? Do I need an account?**
A: It is completely free with no sign-up, no limits, and no ads cluttering the workspace.
**Q: Can it detect dates or enums?**
A: Date strings are kept as `string` (safer than guessing). String values are typed as `string` rather than literal unions, so the output stays stable as your data changes.
---
### JSON to XML Converter
URL: https://go-tools.org/tools/json-to-xml
Paste JSON, get XML instantly. Converts objects, arrays, and @_ attributes in-browser — nothing uploaded. Free, private, no signup required.
#### What is JSON-to-XML Conversion and How Does It Work?
JSON (JavaScript Object Notation) and XML (Extensible Markup Language) are both structured data formats, but they have fundamentally different models: JSON is a tree of objects, arrays, strings, numbers, booleans, and null values with no concept of attributes or document root constraints; XML is a tree of elements that may carry attributes and text content, and the document must have exactly one root element. Converting from JSON to XML requires a set of conventions to bridge this mismatch.
This tool uses the most widely adopted convention — the same one used by fast-xml-parser (Node.js), xmltodict (Python), and JAXB (Java) — applied in reverse:
**1. Root element normalization.** The single most important difference between JSON and XML is the root constraint. JSON has no root concept; XML requires exactly one. The converter handles four cases automatically. A single-key object uses that key as the XML root: { "config": {...} } → header.payload.signature. The header describes how the token is signed (the alg claim — for example, HS256 or RS256 — and the typ claim, usually 'JWT'). The payload carries the claims: registered claims like iss, sub, aud, exp, iat, plus whatever custom claims the issuer needs (role, scope, email, tenant ID). The signature is a cryptographic proof, computed over the header and payload with the issuer's secret or private key, that lets the recipient detect tampering.
Crucially, a JWT is encoded, not encrypted. Anyone with the token can read its payload — decoding is just Base64URL and JSON parsing. The security guarantee comes from the signature: an attacker can read a JWT, but cannot produce a different JWT that passes signature verification without the signing key. That is why JWTs are safe to pass over the network, but unsafe to fill with secrets.
A JWT decoder shows you exactly what a token contains — algorithm, claims, expiration — without touching the signature. It is the fastest way to answer 'is this token expired?', 'what role does this user have?', 'which issuer minted this token?', or 'is this an alg:none token I should reject?'. All decoding in this tool runs locally in your browser, so pasting a live production token is safe.
JWT work often pairs with other developer tools. You may need to decode a Base64URL-wrapped segment when debugging a malformed token, URL-decode an Authorization header after capturing it from a proxy, or convert the exp claim to a human date manually. For a deeper walkthrough of how JWTs are signed, verified, and rotated in production, see our Base64 fundamentals guide — Base64URL is the foundation every JWT is built on.
```
// Decode a JWT in the browser — header & payload only
function decodeJwt(token) {
const [h, p, s] = token.split('.');
const pad = (seg) => seg + '==='.slice((seg.length + 3) % 4);
const decode = (seg) => JSON.parse(
atob(pad(seg).replace(/-/g, '+').replace(/_/g, '/'))
);
return { header: decode(h), payload: decode(p), signature: s };
}
const { header, payload } = decodeJwt(token);
console.log(header); // → { alg: 'HS256', typ: 'JWT' }
console.log(payload); // → { sub: 'user_123', exp: 1999999999, ... }
// Expiration check
const expired = payload.exp * 1000 < Date.now();
```
#### FAQ
**Q: How do I decode a JWT token online?**
A: Paste the full JWT — all three dot-separated segments (header.payload.signature) — into the decoder above. Decoding happens instantly in your browser: the header and payload are Base64URL-decoded to readable JSON, and the signature is displayed as a raw string. A status row surfaces the signing algorithm, issued-at time, and expiration, so you can spot an expired token at a glance. To decode a JWT manually, split the token on dots, Base64URL-decode the first two segments, and parse them as JSON — anyone with the token can read its claims because the payload is encoded, not encrypted. This decoder is safe to use with production tokens because nothing ever leaves your device: no network request, no logging, no tracking.
**Q: What is a JWT (JSON Web Token)?**
A: A JSON Web Token (JWT) is a compact, URL-safe credential that carries claims between two parties. Defined in RFC 7519, it consists of three Base64URL-encoded sections joined by dots: the header (algorithm and token type), the payload (claims — data about the user and the token itself), and the signature (a cryptographic proof that the token was issued by a trusted party). JWTs are the standard way to represent access tokens in OAuth 2.0 and ID tokens in OpenID Connect.
**Q: Is my token safe with this JWT decoder?**
A: Yes. All decoding runs in your browser using native JavaScript (atob and TextDecoder). Your token is never sent to a server, never logged, never stored, and never used for analytics. There are no cookies and no tracking. This matters because JWTs can contain live access tokens — pasting them into a remote debugger would be equivalent to handing over a credential. Our tool is safe to use with production tokens.
**Q: How does a JWT decoder work?**
A: A JWT decoder splits the token by dots into three parts, Base64URL-decodes the header and payload, and parses them as JSON. The signature is left as an opaque Base64URL string because verifying it requires the issuer's secret or public key — something a client-side decoder cannot do safely. This means decoding is instant and reveals the claims, but you must verify the signature server-side with the correct key before trusting anything inside.
**Q: Can this tool verify a JWT signature?**
A: No, and it intentionally does not. Signature verification requires the issuer's secret (for HMAC) or public key (for RSA/ECDSA/EdDSA), which should never be pasted into a public web tool. Verification must happen on your server, in your auth middleware, or inside an SDK that has access to your JWKS endpoint. This decoder is for inspecting what a token claims — it does not imply the token is authentic or untampered.
**Q: What are iat, exp, nbf, iss, aud, sub, and jti?**
A: These are the registered claims from RFC 7519. iat (issued at) is the Unix timestamp when the token was created. exp (expiration) is when the token stops being valid — this tool converts it to a human-readable date and marks the token as expired if exp is in the past. nbf (not before) is the earliest time the token can be used. iss (issuer) identifies who created the token. aud (audience) names the intended recipient. sub (subject) identifies the principal — usually a user ID. jti is a unique token ID used to prevent replay. Application-specific claims (role, scope, email, name) live alongside these.
**Q: My JWT is expired — why does the decoder still decode it?**
A: Decoding is not the same as validating. A JWT decoder reads the content regardless of expiration, so you can inspect an expired or otherwise invalid token to debug why it was rejected. The 'Expired' badge in this tool compares the exp claim against your local clock and flags tokens whose exp is in the past. A real authentication server would reject the token outright — but a decoder that refused to show expired tokens would be useless for debugging.
**Q: What is the difference between JWT, JWS, and JWE?**
A: JWT is the general concept — a JSON object encoded as a compact token. JWS (RFC 7515) is a signed JWT: the payload is readable by anyone who decodes it, and a signature proves it was not tampered with. This is by far the most common JWT you will encounter. JWE (RFC 7516) is an encrypted JWT: the payload itself is ciphertext and cannot be decoded without the decryption key. This tool decodes JWS tokens. A JWE token will decode only to its header — the encrypted payload is not readable without the key.
**Q: Why is alg:none dangerous?**
A: A JWT with alg:none has no signature — anyone can construct one, claiming to be any user. Early JWT libraries accepted alg:none by default, leading to a well-known class of authentication bypasses where an attacker would strip the signature, set alg to none, and forge an admin token. Every mature JWT library now rejects alg:none unless explicitly allowed, and you should never accept it for authenticated requests. This decoder will still show you an alg:none token, because inspecting one during debugging is legitimate — but treat any such token received in production as hostile.
**Q: Which algorithms does this JWT decoder support?**
A: Decoding the header and payload works for every algorithm, because decoding only needs Base64URL and JSON parsing — it is algorithm-agnostic. The tool correctly reads tokens signed with HS256, HS384, HS512 (HMAC), RS256, RS384, RS512 (RSA + SHA), PS256, PS384, PS512 (RSA-PSS), ES256, ES384, ES512 (ECDSA), EdDSA (Ed25519/Ed448), and unsigned tokens (alg:none). Only signature verification is algorithm-specific, and this tool does not perform verification.
**Q: Should I store JWTs in localStorage or cookies?**
A: Prefer HttpOnly, Secure, SameSite=Strict cookies for session tokens. A token in localStorage is readable by any JavaScript that runs on the page, so a single XSS vulnerability leaks every active session. HttpOnly cookies are invisible to JavaScript, which shrinks the blast radius of XSS to what an attacker can do within a live page — not a stolen token they can replay for days. If you must use localStorage (for example, for cross-domain apps), keep access token lifetimes short (minutes, not hours) and use a separate refresh token in an HttpOnly cookie.
**Q: How do I decode a JWT in Node.js, Python, or Go?**
A: Node.js: jsonwebtoken.decode(token) for read-only, jsonwebtoken.verify(token, key) for verification. Python: PyJWT.decode(token, options={'verify_signature': False}) to read, pass a key to verify. Go: jwt.ParseUnverified(token, claims) for read-only, jwt.Parse(token, keyFunc) for verification. In every language, never verify with options={'verify_signature': False} in production code — that is what this web tool does deliberately for debugging, and it is only safe when you are inspecting, not authenticating.
**Q: What is the maximum size of a JWT?**
A: The JWT standard does not impose a hard limit, but headers in most web servers default to around 8 KB. Keep tokens under 4 KB so they fit comfortably in Authorization headers and cookies. If your token is larger than that, you are probably putting too many claims in the payload — move bulky data behind an opaque session ID and fetch it from your backend when needed. Bloated JWTs also get costly on every request because they are sent with every API call.
**Q: I pasted my token and got 'Invalid JWT format' — what's wrong?**
A: A valid JWT has exactly three parts separated by dots: header.payload.signature. Common causes: (1) you accidentally copied only the payload segment, (2) whitespace or newlines were pasted in the middle, (3) the token was truncated in transit (common with terminal wrapping), (4) the token is a JWE where the format is header.encryptedKey.iv.ciphertext.tag (five segments), or (5) the token was URL-encoded and you need to URL-decode it first. Check the raw value your API returned — most editors show invisible characters on hover.
**Q: Can I decode a JWT without the secret key?**
A: Yes — the header and payload are Base64URL-encoded, not encrypted. Anyone who has the token can read its claims without any key. This is by design: the payload is meant to be readable so the recipient can make authorization decisions from it. The secret or public key is only required to verify that the token has not been tampered with. This is why you must never put sensitive data (passwords, private keys, PII beyond what the recipient already knows) inside a JWT payload.
**Q: My JWT works in Postman but my backend rejects it — how do I debug?**
A: Decode the token here and check: (1) exp — is it in the future relative to the server's clock? Server clock skew is a frequent culprit. (2) iss / aud — do they exactly match what your backend expects? A mismatch on aud is the most common false-negative. (3) alg — does your verification code allow that algorithm? An HS256 token will fail against a library configured for RS256 only. (4) kid — if you use key rotation, is the key ID in the header present in your JWKS? (5) signature — have you pasted the right secret/public key? This decoder surfaces (1), (2), (3), and (4) in the header and payload views so you can eliminate them quickly.
---
### JWT Encoder & Generator
URL: https://go-tools.org/tools/jwt-encoder
Free online JWT generator & encoder. Build the header and payload, sign with HS256, RS256, or ES256 instantly. 100% in-browser — your secret and key never leave your device.
#### What is a JWT Encoder?
A JWT encoder builds and cryptographically signs a JSON Web Token from a header and a payload of claims. A JWT, defined in RFC 7519, is three Base64URL-encoded sections joined by dots: header.payload.signature. The header names the signing algorithm; the payload carries the claims (who the token is about, what it can do, when it expires); and the signature is a cryptographic proof, computed over the header and payload with a secret or private key, that lets a recipient detect tampering.
"JSON Web Token (JWT) is a compact claims representation format intended for space-constrained environments such as HTTP Authorization headers and URI query parameters." — RFC 7519, Section 1
Encoding is the inverse of decoding. A JWT decoder reads an existing token's claims; an encoder takes claims you supply and produces a brand-new signed token. The signing step is what separates a real JWT from arbitrary Base64 — without a valid signature, no verifier will accept the token. This tool signs using the browser's native Web Crypto API across the HMAC (HS), RSA (RS, PS), and ECDSA (ES) families, so the entire operation happens on your device with zero dependencies and zero network calls.
Developers reach for a JWT encoder constantly: to mint a token that exercises a protected API endpoint, to reproduce the exact claim shape an OAuth server issues so a bug can be debugged, to build fixtures for integration tests, or to hand a teammate a ready-to-use Bearer token for a curl command. Because the payload is encoded, not encrypted, a JWT is safe to pass over the network but must never carry secrets — anyone with the token can read every claim, and only the signature stops them from changing one.
JWT work pairs naturally with other developer tools. After signing, decode the token to confirm its claims, convert exp and iat between Unix time and human dates, or compute a SHA-256 hash when you need the underlying hash function that HS256's HMAC is built on. Because every JWT segment is Base64URL-encoded, a Base64 tool is handy when you inspect a token by hand; for an in-depth look at the encoding, see our Base64 fundamentals guide.
```
// Sign a JWT in the browser with the Web Crypto API (HS256)
async function encodeJwt(payload, secret) {
const b64url = (bytes) =>
btoa(String.fromCharCode(...new Uint8Array(bytes)))
.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
const enc = (obj) =>
b64url(new TextEncoder().encode(JSON.stringify(obj)));
const header = { alg: 'HS256', typ: 'JWT' };
const signingInput = `${enc(header)}.${enc(payload)}`;
const key = await crypto.subtle.importKey(
'raw', new TextEncoder().encode(secret),
{ name: 'HMAC', hash: 'SHA-256' }, false, ['sign']);
const sig = await crypto.subtle.sign(
'HMAC', key, new TextEncoder().encode(signingInput));
return `${signingInput}.${b64url(sig)}`;
}
const token = await encodeJwt({ sub: 'user_123', exp: 1999999999 }, 'my-secret');
// → eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTk5OTk5OTk5OX0....
```
#### FAQ
**Q: How do I generate a JWT online?**
A: Edit the payload JSON in the box above, choose a signing algorithm (HS256 is the default and needs only a secret), and enter your secret or paste a PKCS8 PEM private key. The signed token appears instantly, with the header, payload, and signature segments color-coded so you can copy the whole thing with one click. Signing runs entirely in your browser using the native Web Crypto API — there is no Generate button to wait on and no request to a server, so it is safe to sign tokens with real keys during development.
**Q: What is a JWT generator?**
A: A JWT generator is a tool that builds and cryptographically signs a JSON Web Token from a header and a payload of claims, producing a header.payload.signature string you can use as a Bearer token. It is the inverse of a JWT decoder: instead of reading an existing token, it creates a new one signed with your secret (HS256) or private key (RS256/ES256). This generator runs entirely in your browser, so the token is produced instantly and your signing key never leaves your device.
**Q: Is this JWT generator free and safe to use?**
A: Yes — it is completely free, with no signup, no ads, and no tracking. It is safe because all signing happens locally in your browser via the Web Crypto API: your payload, secret, and private key are never uploaded, logged, or stored, and the tool makes no network requests at all. That makes it suitable even when you are working with sensitive keys, though using disposable test keys is always the safest habit.
**Q: Is it safe to enter my secret or private key here?**
A: Yes. Signing happens locally in your browser; your secret and private key are never sent to a server, never logged, never stored, and never used for analytics. There are no cookies and no tracking. This matters because a JWT signing key can mint valid credentials — pasting it into a remote tool would be equivalent to handing over the keys to your auth system. Because everything runs client-side, this encoder is safe to use with production keys, but you should still prefer disposable or test keys whenever possible.
**Q: What is the difference between HS256 and RS256?**
A: HS256 (HMAC-SHA256) uses a single shared secret to both sign and verify. It is simple and fast, but every party that can verify the token can also create one, so the secret must stay on trusted servers only. RS256 (RSA-SHA256) uses a key pair: you sign with a private key and others verify with the public key. This lets you distribute the public key freely — to client apps, partner services, or a JWKS endpoint — without giving anyone the ability to forge tokens. Use HS256 for symmetric, single-owner systems; use RS256 or ES256 when verifiers should not be able to mint tokens.
**Q: Which algorithms does this JWT encoder support?**
A: It signs with HS256, HS384, HS512 (HMAC with a shared secret), RS256, RS384, RS512 (RSA PKCS#1 v1.5), PS256, PS384, PS512 (RSA-PSS), and ES256, ES384, ES512 (ECDSA on P-256, P-384, and P-521). All of them are produced with the browser's native Web Crypto API, so there are no third-party libraries and nothing leaves your machine. HMAC algorithms take a text or Base64 secret; the RSA and ECDSA families take a PKCS8 PEM private key.
**Q: How do I set the exp (expiration) claim?**
A: Add an exp claim to the payload as a Unix timestamp in seconds — for example "exp": 1999999999. The quickest way is the exp +1h chip below the payload, which inserts an expiration one hour from now. You can also add iat (issued-at) and nbf (not-before) the same way. Remember that exp is in seconds, not milliseconds, and that verifiers compare it against their own clock, so keep server times in sync to avoid premature rejections. To convert a human date to a Unix timestamp, use our Unix timestamp converter.
**Q: How do I get a PKCS8 PEM private key for RS256 or ES256?**
A: For RSA: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private.pem. For ECDSA P-256: openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ec-private.pem. Both commands emit a PKCS8 PEM block beginning with -----BEGIN PRIVATE KEY-----, which is exactly what this tool expects. Paste the whole block, including the header and footer lines. The matching public key — used to verify the token — can be derived with openssl pkey -in private.pem -pubout. If you would rather not touch the command line, our RSA key pair generator produces the same PKCS8 block in your browser, and can switch it to the traditional PKCS1 layout when something else needs that.
**Q: How do I verify the token I just generated?**
A: Paste it into our JWT decoder to confirm the header and payload decode as expected. To verify the signature, use your server or an SDK with the correct key: jwt.verify(token, secretOrPublicKey, { algorithms: ['HS256'] }) in Node.js, PyJWT.decode(token, key, algorithms=['RS256']) in Python, or jwt.Parse(token, keyFunc) in Go. Never verify with an empty algorithm list or with verify_signature=False in production — always pin the exact algorithm you expect.
**Q: What should I put in the payload?**
A: Keep it lean. The registered claims from RFC 7519 are iss (issuer), sub (subject — usually a user ID), aud (audience), exp (expiration), nbf (not before), iat (issued at), and jti (token ID). Alongside these you can add application claims like role, scope, or email. Do not put secrets in the payload — a JWT is encoded, not encrypted, so anyone with the token can read every claim. Keep tokens under about 4 KB so they fit in Authorization headers and cookies.
**Q: Is a JWT encrypted?**
A: No. A standard signed JWT (a JWS) is Base64URL-encoded, not encrypted. The signature proves the token has not been tampered with and was issued by someone holding the key, but the header and payload are fully readable by anyone who has the token. If you need the payload itself to be confidential, you need a JWE (encrypted JWT), which is a different format. This tool produces signed JWS tokens, the kind used for the vast majority of authentication and authorization flows.
**Q: Why is my RS256 or ES256 signing failing?**
A: The most common causes are: (1) the key is not in PKCS8 format — convert a traditional -----BEGIN RSA PRIVATE KEY----- (PKCS1) key with openssl pkcs8 -topk8 -nocrypt -in old.pem -out pkcs8.pem; (2) the curve does not match the algorithm — ES256 needs a P-256 key, ES384 needs P-384, ES512 needs P-521; (3) you pasted a public key or a certificate instead of the private key; or (4) the key is encrypted with a passphrase, which the Web Crypto API cannot import directly. Decrypt it first with openssl pkey and paste the unencrypted PKCS8 block.
**Q: Does this tool support the alg:none unsigned token?**
A: No, and deliberately so. An alg:none token has no signature, which means anyone can forge one — it is the root of a classic JWT authentication-bypass vulnerability. Because the entire point of an encoder is to produce a signed token, this tool only offers real signing algorithms. If you are studying alg:none for security research, you can construct one by hand by Base64URL-encoding the header and payload and leaving the signature segment empty — the token still ends with a trailing dot (header.payload.) — but you should never accept such a token in production.
**Q: Can I generate a JWT in code instead?**
A: Yes. In Node.js: jsonwebtoken.sign(payload, secret, { algorithm: 'HS256', expiresIn: '1h' }). In Python: jwt.encode(payload, key, algorithm='RS256') with PyJWT. In Go: jwt.NewWithClaims(jwt.SigningMethodES256, claims).SignedString(privateKey). This tool is the fastest way to produce a token for a quick test, a curl request, or a fixture — but in application code you should generate tokens server-side with a maintained library and a key loaded from your secrets manager, never hard-coded.
---
### Free JWT Secret Generator — HS256/384/512
URL: https://go-tools.org/tools/jwt-secret-generator
Generate a strong, RFC-correct JWT secret for HS256/384/512 — 100% in your browser, never sent to a server. base64url, base64 or hex; copy for .env.
#### What is a JWT secret generator?
A JWT secret generator produces the random signing key that an HMAC-signed JSON Web Token uses to prove it has not been tampered with. When you sign a token with HS256, HS384, or HS512, the algorithm runs HMAC over the token's header and payload using a single shared secret; the verifier recomputes the same HMAC with the same secret and accepts the token only if the signatures match. The whole security of that scheme rests on the secret being long and unpredictable — which is exactly what this tool creates: a high-entropy random string, generated in your browser, sized correctly for the algorithm you pick.
It is worth being precise about what this tool does and does not do. It generates the secret key — the value you put in your JWT_SECRET environment variable — not a finished token. If you want to assemble a header and payload and sign them into an actual JWT, that is the job of the JWT Encoder; to take an existing token apart and verify its signature, use the JWT Decoder. Think of the secret as the key and the encoder as the lock it operates: you generate the key once, store it safely, and reuse it to sign and verify many tokens.
How long should the key be? The answer is fixed by the spec, not by preference. RFC 7518 §3.2 — the JSON Web Algorithms standard — requires that an HMAC key be at least as large as the hash output: "A key of the same size as the hash output (for instance, 256 bits for HS256) or larger MUST be used." That gives a clean table the generator follows automatically:
| Algorithm | HMAC | Min bytes | Min bits | hex chars | base64 chars | base64url chars |
|-----------|------|-----------|----------|-----------|--------------|-----------------|
| HS256 | HMAC-SHA-256 | 32 | 256 | 64 | 44 | 43 |
| HS384 | HMAC-SHA-384 | 48 | 384 | 96 | 64 | 64 |
| HS512 | HMAC-SHA-512 | 64 | 512 | 128 | 88 | 86 |
The character counts come from the RFC 4648 encodings of those byte lengths: hex doubles the byte count; base64 expands by 4⁄3 with padding; base64url drops the padding, so a 32-byte key is 43 base64url characters rather than 44. base64url is JWT's native encoding — URL-safe alphabet, no padding — which is why it is the default output here; a secret in base64url can sit in a header, a URL, or a config value with no escaping.
Randomness is the part you cannot compromise on. This generator draws its bytes from crypto.getRandomValues, the browser's cryptographically secure pseudo-random number generator, the same primitive that backs Web Crypto key generation. It never uses Math.random, which is fast but predictable and completely unsuitable for a signing key — a predictable RNG means a guessable secret, and a guessable secret means forgeable tokens. Because HMAC verification happens locally with the shared secret, an attacker who captures a token can brute-force a weak key offline with no rate limit; tools such as hashcat (mode 16500) and jwt_tool exist precisely to do this. A full-entropy 32-byte random key, on the other hand, is computationally out of reach. The lesson is blunt: never use a password, a dictionary word, or a hand-typed string as a JWT secret — generate a random one.
Finally, generating the key client-side is itself a security property. A signing secret should never be transmitted to a third party, not even the site that helps you create it. Every byte here is produced and encoded in your browser; nothing is uploaded, logged, or stored. When you are ready to ship the key, the Copy for .env button hands you a JWT_SECRET=… line, and if you need it folded into a larger configuration the JSON to .env converter can help. Generate, copy, store it in a secrets manager — and rotate it with a kid header and overlapping validity windows when the time comes.
```
// The secret you generate here goes straight into your signing code.
// Node.js with jsonwebtoken — the JWT_SECRET env var holds the key.
import jwt from 'jsonwebtoken';
const secret = process.env.JWT_SECRET; // e.g. base64url value from this tool
// Sign a token with HS256 (HMAC-SHA-256).
const token = jwt.sign({ sub: 'user-42', role: 'member' }, secret, {
algorithm: 'HS256',
expiresIn: '15m'
});
// Verify it — pin the algorithm to a whitelist; never trust the token's alg.
const payload = jwt.verify(token, secret, { algorithms: ['HS256'] });
// ---------------------------------------------------------------
// Python with PyJWT — same secret, same algorithm pinning.
// import jwt
// token = jwt.encode({"sub": "user-42"}, key, algorithm="HS256")
// payload = jwt.decode(token, key, algorithms=["HS256"]) # whitelist!
// ---------------------------------------------------------------
// Equivalent-strength CLI generation (32 bytes for HS256):
// openssl rand -base64 32
// node -e "console.log(require('crypto').randomBytes(32).toString('base64url'))"
// python -c "import secrets; print(secrets.token_urlsafe(32))"
```
#### FAQ
**Q: Is my generated JWT secret sent to your server?**
A: No. The secret is generated entirely in your browser with crypto.getRandomValues, the platform's cryptographically secure random number generator. The bytes are produced on your device, encoded locally, and shown only to you. Nothing is uploaded, nothing is logged, nothing is written to disk, and nothing is sent to any third party — open DevTools → Network and you will see zero requests fire when you click Regenerate or Copy. That means a key you generate here is yours alone the instant it appears; no server ever observes it. This is the whole point of generating a signing secret client-side rather than on a website that could, in principle, keep a copy of every key it hands out.
**Q: How do I generate a secure JWT secret?**
A: Three steps. First, pick the signing algorithm your application uses — HS256, HS384, or HS512 — and the generator immediately sizes the key to the RFC 7518 §3.2 minimum for that variant (32, 48, or 64 bytes), so you never hand-pick a number or risk an undersized key. Second, leave the encoding on base64url (JWT's native, URL-safe format) or switch to base64 or hex if your config loader expects one of those. Third, click Copy — or Copy for .env to get a ready-to-paste JWT_SECRET=… line — and store the value in a secrets manager or environment variable, never in source control. Because every byte comes from crypto.getRandomValues, a 32-byte key already carries 256 bits of entropy, which is far beyond the reach of the offline brute-force attacks that break human-chosen secrets. Prefer the command line? The tool also prints equivalent openssl, Node, and Python one-liners you can paste into a terminal.
**Q: How long should an HS256 JWT secret be?**
A: At least 32 bytes (256 bits). RFC 7518 §3.2 — the JSON Web Algorithms spec — states that for HMAC signatures "a key of the same size as the hash output (for instance, 256 bits for HS256) or larger MUST be used." HS256 signs with HMAC-SHA-256 (256-bit hash), so the minimum key is 32 bytes; HS384 uses HMAC-SHA-384 and needs at least 48 bytes (384 bits); HS512 uses HMAC-SHA-512 and needs at least 64 bytes (512 bits). This generator picks the correct minimum automatically when you choose the algorithm, and you can request a longer key. A shorter key is not just weaker — it violates the spec and some libraries will refuse to sign with it.
**Q: What is the difference between base64url, base64, and hex, and which should I pick?**
A: All three encode the same random bytes; they differ only in the character alphabet, not in entropy. base64url is JWT's native encoding — it uses a URL-safe alphabet (- and _ instead of + and /) and omits padding, so it never needs escaping in a token, a URL, or a header. That is why it is the default here. Standard base64 uses +, /, and = padding; choose it when a config loader or library specifically expects classic base64. hex (base16) writes each byte as two characters 0–f, producing a longer but unambiguous string that is handy when a system rejects non-alphanumeric characters. For a JWT_SECRET environment variable, base64url is the safest default; any of the three works as long as you store the exact string and feed it back to your signing library unchanged.
**Q: Can a weak JWT secret be cracked?**
A: Yes — and this is the single biggest risk with HMAC-signed JWTs. Because HS256/384/512 use one shared secret, anyone who holds a token can run an offline brute-force or dictionary attack against the signature with no rate limit and no server contact. Tools like hashcat (mode 16500 targets JWT) and jwt_tool are purpose-built for this; on commodity GPUs a low-entropy secret can typically fall in seconds to hours, and a dictionary word or a leaked password can fall almost immediately. A full-entropy 32-byte random key from this generator is far beyond the reach of brute force. Once an attacker recovers the secret they can forge any token — including one that claims admin privileges — so secret strength is not optional. Generate the signing key with a CSPRNG, never a human-chosen string. For a deeper treatment of weak-secret, alg-confusion, and token-replay attacks, see our guide to JWT security best practices.
**Q: Can I use a password as my JWT secret?**
A: You can, but you should not. A human-memorable password — even a long passphrase — carries far less entropy than 32 random bytes, which makes it a realistic target for the offline brute-force and dictionary attacks described above. JWT secrets are machine-to-machine credentials; nobody needs to memorize them, so there is no reason to trade entropy for memorability. Generate a random secret here, store it in a secrets manager or an environment variable, and let your application read it. If you need memorable credentials for a different purpose, that is a job for a Password Generator or, for storing user passwords, a one-way hash from the bcrypt Generator — not for a token-signing key.
**Q: How do I rotate a JWT secret without breaking live tokens?**
A: Rotate with overlap rather than a hard cutover. Add a key identifier (the kid header) to the tokens you sign so a verifier knows which secret to check against, and publish your active keys — typically through a JWKS endpoint your services read. To rotate: generate a new secret here, start signing new tokens with the new kid while still accepting the previous key for verification, and only retire the old key after every token signed with it has expired. That overlap window means no valid session is invalidated mid-flight. In a suspected compromise, skip the graceful overlap: rotate immediately, drop the old key from the accepted set, and force re-authentication so leaked tokens stop verifying at once.
**Q: How is an HMAC (HS*) key different from an RSA or ECDSA (RS*/ES*) key?**
A: They solve the same problem with opposite key models. HS256/384/512 are HMAC algorithms: they use one symmetric secret — the kind this tool generates — that both signs and verifies, so every party that can verify a token can also forge one. That is simple and fast and ideal when a single service both issues and checks its own tokens. RS* (RSA) and ES* (ECDSA) are asymmetric: they use a key pair, where a private key signs and a separate public key only verifies. You hand the public key to anyone who needs to validate tokens without ever exposing the signing key — the right choice when an identity provider issues tokens that many independent services verify. This generator produces HMAC symmetric secrets only — for the asymmetric side, our RSA key pair generator creates RSA, ECDSA and Ed25519 pairs in the browser. To assemble and sign an actual token with the key you generate, use the JWT Encoder; to inspect and verify one, use the JWT Decoder.
---
### Length Unit Converter — Metric, Imperial & More
URL: https://go-tools.org/tools/length-converter
Convert between 16 length units instantly — metric, imperial, nautical & astronomical. 1 inch = 2.54 cm. Free, private, runs in your browser.
#### What Is a Length Unit Converter?
A length unit converter is a tool that translates distance and length measurements between different units of measure — bridging the metric system (meter, kilometer, centimeter) and the imperial system (inch, foot, yard, mile), as well as specialized units used in science, navigation, and astronomy.
The metric system, used by most of the world, is decimal-based: each unit differs from the next by a power of 10. The core unit is the meter, officially defined since 2019 by the International Bureau of Weights and Measures (BIPM) in the International System of Units (SI) as the distance light travels in a vacuum in exactly 1/299,792,458 of a second — anchoring the meter to a universal physical constant rather than any physical artifact. Prefixes like kilo- (1,000), centi- (0.01), milli- (0.001), micro- (0.000001), and nano- (0.000000001) scale the meter up or down. The imperial system, still common in the United States, uses inches, feet (12 inches), yards (3 feet), and miles (5,280 feet).
Beyond everyday units, this converter supports nautical miles (used in aviation and maritime navigation), and astronomical units like the light year (9.461 trillion km), the astronomical unit (Earth-Sun distance, ~149.6 million km), and the parsec (~3.26 light years). It also includes the fathom (6 feet, used for water depth) and the furlong (220 yards, used in horse racing).
All conversions use the internationally defined exact factors established by the 1959 international yard and pound agreement, as published by BIPM and NIST, ensuring precise results traceable to the SI definition of the meter. Processing runs entirely in your browser — no data is transmitted to any server, so your measurements stay completely private.
Need to convert other measurement types? Try our weight converter for mass units, volume converter for liquid measurements, or temperature converter for Celsius, Fahrenheit, and Kelvin.
```
// Key conversion factors (exact):
// 1 inch = 2.54 cm
// 1 foot = 0.3048 m
// 1 yard = 0.9144 m
// 1 mile = 1.609344 km
// JavaScript conversion examples:
const inchesToCm = (inches) => inches * 2.54;
const feetToMeters = (feet) => feet * 0.3048;
const milesToKm = (miles) => miles * 1.609344;
const kmToMiles = (km) => km / 1.609344;
console.log(inchesToCm(12)); // 30.48
console.log(feetToMeters(6)); // 1.8288
console.log(milesToKm(26.2)); // 42.164928
```
#### FAQ
**Q: How many centimeters are in an inch?**
A: There are exactly 2.54 centimeters in one inch. This is not an approximation — it is the exact conversion factor defined by the international yard and pound agreement of 1959. To convert inches to centimeters, multiply by 2.54. To convert centimeters to inches, divide by 2.54. For example, 12 inches = 30.48 cm, and 10 cm = 3.937 inches.
**Q: How many feet are in a meter?**
A: One meter equals approximately 3.28084 feet, or more precisely, 1 meter = 3.2808398950131 feet. Conversely, 1 foot = 0.3048 meters exactly. This means a 6-foot person is about 1.8288 meters tall. To convert meters to feet, multiply by 3.28084. To convert feet to meters, multiply by 0.3048.
**Q: What is the formula to convert inches to cm?**
A: To convert inches to centimeters, multiply the inch value by 2.54. The formula is: cm = inches × 2.54. This is an exact conversion factor defined by international agreement in 1959. For example, 6 inches = 6 × 2.54 = 15.24 cm. To convert back from cm to inches, divide by 2.54: inches = cm ÷ 2.54.
**Q: What is a nautical mile and how does it differ from a regular mile?**
A: A nautical mile equals exactly 1,852 meters (about 1.151 regular miles or 6,076 feet). It was originally defined as one minute of arc along a meridian of the Earth, making it naturally suited for navigation. A regular (statute) mile equals 1,609.344 meters or 5,280 feet. Nautical miles are used in aviation and maritime navigation because they relate directly to degrees of latitude: 60 nautical miles = 1 degree of latitude.
**Q: Which countries still use the imperial system?**
A: Only three countries primarily use the imperial system for everyday measurements: the United States, Myanmar (Burma), and Liberia. The UK uses a mix — road distances are in miles, but most other measurements are metric. Canada officially uses metric but commonly uses feet and inches for personal height and real estate. Most scientific, medical, and international trade contexts use the metric system worldwide.
**Q: How tall is 5'7 in cm?**
A: 5 feet 7 inches equals 170.18 centimeters. To calculate: convert feet to inches (5 × 12 = 60), add remaining inches (60 + 7 = 67 total inches), multiply by 2.54 (67 × 2.54 = 170.18 cm). Common heights: 5'0" = 152.4 cm, 5'5" = 165.1 cm, 5'7" = 170.18 cm, 5'10" = 177.8 cm, 6'0" = 182.88 cm, 6'2" = 187.96 cm.
**Q: What is a light year and how far is it?**
A: A light year is the distance that light travels in one year in a vacuum — approximately 9.461 trillion kilometers (9.461 × 10¹² km) or about 5.879 trillion miles. Despite the name, a light year is a unit of distance, not time. For perspective, light from the Sun takes about 8 minutes to reach Earth (1 AU = 149.6 million km), while the nearest star system, Alpha Centauri, is about 4.37 light years away. Light years are used to express distances between stars and galaxies because using kilometers would require unwieldy numbers.
**Q: How accurate is this length converter?**
A: This converter uses the internationally defined exact conversion factors: 1 inch = 25.4 mm exactly, 1 yard = 0.9144 m exactly, and 1 mile = 1,609.344 m exactly. All calculations use IEEE 754 double-precision floating-point arithmetic, providing at least 15 significant digits of precision. For everyday conversions, the results are more accurate than any physical measurement. The only limitation is the inherent rounding of floating-point numbers at extreme precision, which affects digits beyond the 15th significant figure.
**Q: How do metric prefixes work for length units?**
A: Metric length units are based on the meter, with prefixes indicating powers of 10. Common prefixes from large to small: kilo (km) = 1,000 m, no prefix (m) = 1 m, centi (cm) = 0.01 m, milli (mm) = 0.001 m, micro (um) = 0.000001 m, and nano (nm) = 0.000000001 m. Each step between adjacent common prefixes is a factor of 1,000 (except centi, which is 1/100 of a meter). This decimal-based system makes metric conversions straightforward: moving the decimal point is all that is required.
**Q: Is my data safe when using this length converter?**
A: Yes, completely. All conversions are performed locally in your browser using JavaScript. No data is sent to any server — there are no network requests, no cookies, and no analytics on your input. The conversion logic runs entirely on your device, meaning your values never leave your browser. You can verify this by disconnecting from the internet and using the tool — it works fully offline once the page has loaded.
**Q: How many feet are in a mile?**
A: There are exactly 5,280 feet in one mile. This relationship is defined by the statute mile, the standard mile used in the United States and United Kingdom. Other useful conversions: 1 mile = 1,760 yards = 63,360 inches = 1,609.344 meters = 1.609344 kilometers. The word 'mile' derives from the Latin 'mille passus' meaning one thousand paces.
**Q: What is the SI unit of length?**
A: The meter (m) is the SI (International System of Units) base unit of length. Since 2019, it is defined as the distance light travels in a vacuum in exactly 1/299,792,458 of a second. All other metric length units are derived from the meter using decimal prefixes: 1 kilometer = 1,000 meters, 1 centimeter = 0.01 meters, 1 millimeter = 0.001 meters, 1 micrometer = 0.000001 meters, 1 nanometer = 0.000000001 meters.
**Q: I need to convert my height from feet to centimeters for a medical form — how do I do it?**
A: First, convert your total height to inches: multiply the feet by 12 and add any remaining inches. For example, 5 feet 9 inches = (5 x 12) + 9 = 69 inches. Then multiply by 2.54 to get centimeters: 69 x 2.54 = 175.26 cm. You can enter 69 in this tool with inches as the source unit and centimeters as the target to get the exact result. Common heights for reference: 5'4" = 162.6 cm, 5'7" = 170.2 cm, 5'10" = 177.8 cm, 6'1" = 185.4 cm. Medical forms worldwide use centimeters, so this conversion comes up frequently for travelers and expats.
**Q: I need to convert kilometers to miles for a US road trip — what is the quickest way?**
A: Multiply kilometers by 0.621 for a quick estimate, or use this tool for exact results. For mental math on the road, a handy trick is the Fibonacci approximation: consecutive Fibonacci numbers approximate the km-to-miles ratio. So 8 km is about 5 miles, 13 km is about 8 miles, 21 km is about 13 miles. For speed limits, 100 km/h is about 62 mph, 120 km/h is about 75 mph, and 130 km/h is about 81 mph. Enter any distance in this tool to get the precise conversion instantly.
**Q: I need to figure out if my furniture will fit through a doorway — how do I convert between inches and centimeters?**
A: Multiply inches by 2.54 to get centimeters, or divide centimeters by 2.54 to get inches. A standard US interior doorway is 80 inches (203 cm) tall and 30-36 inches (76-91 cm) wide. If your furniture is measured in centimeters (common for IKEA and European brands), divide by 2.54 to compare with your doorway in inches. For example, a 200 cm tall bookshelf is 78.7 inches — it will fit through a standard door with about 1.3 inches to spare. Always measure the diagonal of the item if you need to tilt it to fit through.
---
### Lorem Ipsum Generator — Free Placeholder Text Tool
URL: https://go-tools.org/tools/lorem-ipsum
Generate Lorem Ipsum placeholder text instantly — by paragraph, sentence, word, byte, or list. Copy or download as plain text, HTML, Markdown, or JSON. 100% free, private, in-browser. No sign-up.
#### What Is Lorem Ipsum?
Lorem Ipsum is the placeholder text the design and publishing world reaches for whenever a layout needs words before the real copy exists. It is deliberately meaningless — a scramble of Latin-looking fragments — so that anyone reviewing the work judges the visual design, the typography, and the spacing instead of getting pulled into reading and editing the message. A block of Lorem Ipsum wraps, breaks, and sets type much like genuine prose because it has a natural-feeling distribution of word and sentence lengths, which is exactly why it beats lazy fillers like "asdf asdf" or repeated "text text text" that distort how a real paragraph would flow.
The text is not invented gibberish. It traces back to a passage from Cicero's "De Finibus Bonorum et Malorum" ("On the Ends of Good and Evil"), a work of moral philosophy written in 45 BC. Somewhere along the way the Latin was garbled — words clipped, reordered, and combined — until it stopped being readable Latin and became the neutral, language-agnostic filler we know. The famous opening, "Lorem ipsum dolor sit amet, consectetur adipiscing elit," is itself a corruption: "Lorem" isn't even a real Latin word; it's the tail of "dolorem" (pain) with its first syllable lost.
Lorem Ipsum entered modern practice through print. In the 1960s the Letraset company printed Lorem Ipsum passages on its dry-transfer lettering sheets, giving graphic designers a ready supply of filler to rub onto layouts. It made the leap to the screen in the 1980s when Aldus included it as sample text in PageMaker, the application that launched desktop publishing. From there it became the default in page-layout software, website templates, and design tools, and today every major design app — from InDesign to Figma — can drop Lorem Ipsum into a frame with a single command.
This generator gives you that same filler on demand, but built for how people actually work in 2026: not just paragraphs, but exact word counts, sentence counts, list items, and precise byte budgets, and not just plain text, but HTML, Markdown, and JSON output for pasting straight into markup, documents, fixtures, and mocks. It runs entirely in your browser, so it is instant, private, and available offline. Pair it with the word counter when you need to match a real content slot's length, or the case converter and JSON formatter when you're shaping the filler into a specific format for a template or test. For the full story of where Lorem Ipsum comes from and when not to use it, read our complete guide to Lorem Ipsum.
```
// Generating Lorem Ipsum (simplified)
const WORDS = ['lorem','ipsum','dolor','sit','amet','consectetur','adipiscing','elit','sed','do','eiusmod','tempor'];
const PREFIX = 'Lorem ipsum dolor sit amet, consectetur adipiscing elit';
const pick = (rng) => WORDS[Math.floor(rng() * WORDS.length)];
function sentence(rng, lead) {
const n = 6 + Math.floor(rng() * 9); // 6-14 words
const words = Array.from({ length: n }, () => pick(rng));
const body = words.join(' ');
return lead ? `${lead}, ${body}.` : `${body[0].toUpperCase()}${body.slice(1)}.`;
}
function paragraph(rng, startWithLorem) {
const n = 3 + Math.floor(rng() * 5); // 3-7 sentences
return Array.from({ length: n }, (_, i) =>
sentence(rng, i === 0 && startWithLorem ? PREFIX : undefined)
).join(' ');
}
// Three random paragraphs, beginning with the canonical line
const text = Array.from({ length: 3 }, (_, i) =>
paragraph(Math.random, i === 0)
).join('\n\n');
```
#### FAQ
**Q: What is this Lorem Ipsum generator and what does it do?**
A: It produces Lorem Ipsum — the standard dummy text used as a placeholder in design and development — in whatever quantity and format you need. You choose a unit (paragraphs, sentences, words, list items, or an exact byte count) and an amount, and the tool generates matching filler text instantly. You can output plain text, HTML (with or
- wrapping), Markdown, or a JSON array, then copy it to your clipboard or download it as a file. The page opens with three paragraphs already generated so you can grab text immediately. Everything runs in your browser with JavaScript — nothing is uploaded, logged, or stored, and no account is required.
**Q: Is the Lorem Ipsum generator free, and do I need to sign up?**
A: It is completely free with no sign-up, no account, no email capture, and no usage limit. There is no premium tier that gates formats or sizes, and the generated text carries no watermark or attribution requirement — it is placeholder text, free for any use. The tool is funded the same way the rest of the site is and asks nothing of you in return for generating text. You can use it as many times as you like, generate as much text as the size ceilings allow, and download the result without ever creating a profile.
**Q: Does my text get sent to a server, or is it private?**
A: Generation happens 100% client-side in your browser. There is no server round-trip: the JavaScript that builds the text runs locally, which is why output appears instantly even at the largest sizes and why the tool keeps working if your connection drops. Nothing you generate is transmitted, logged, stored, or analyzed. This matters less for placeholder text than for a tool that processes your own input, but it means the generator is fast, reliable, and verifiable — you can open your browser's Network tab and confirm that clicking Regenerate triggers zero network requests.
**Q: What is Lorem Ipsum and where does it come from?**
A: Lorem Ipsum is scrambled, meaningless Latin-like text used to fill space in a layout so designers and clients judge the visual design without being distracted by readable content. It is not random gibberish: it derives from a passage of Cicero's "De Finibus Bonorum et Malorum" ("On the Ends of Good and Evil"), written in 45 BC, with words altered, added, and removed so it no longer reads as real Latin. The text entered design culture in the 1960s when the Letraset company printed Lorem Ipsum passages on its dry-transfer lettering sheets, and it spread worldwide in the 1980s when Aldus bundled it into the PageMaker desktop-publishing software. The canonical opening — "Lorem ipsum dolor sit amet, consectetur adipiscing elit" — is the fragment most people recognize.
**Q: Why use Lorem Ipsum instead of real text or just 'asdf asdf'?**
A: Placeholder text exists so the eye evaluates layout, typography, and spacing rather than reading the words. Real copy pulls reviewers into editing the message instead of the design, and obvious filler like "asdf asdf" or repeated "text text text" produces unnatural word lengths and line breaks that misrepresent how real content will flow. Lorem Ipsum has a roughly normal distribution of word and sentence lengths, so a paragraph of it wraps, hyphenates, and sets type much like genuine prose would. That makes it a faithful stand-in for judging line length, leading, column width, and the rhythm of a text block before the real words are ready.
**Q: How do I generate Lorem Ipsum directly as HTML?**
A: Set the Format control to HTML. Paragraph output is then wrapped in
…
tags (one per paragraph), and list output is wrapped in a- with each item in its own
- . The result is ready to paste straight into a template, a component, a Storybook story, or a CMS rich-text editor without the find-and-replace step you would otherwise do on plain text. If you want the text without markup, leave Format on Plain text. Markdown format is also available for blank-line-separated paragraphs and hyphen-prefixed lists, and JSON format returns an array of strings for fixtures and mocks.
**Q: Can I generate an exact number of words, characters, or paragraphs?**
A: Yes. The Generate control selects the unit and the Amount control sets the exact quantity. Choose Words to get a precise word count, Paragraphs or Sentences for those units, List items for short fragments, or Bytes to fill an exact byte budget — useful for testing a database column width or a character-limited field. Because the Lorem vocabulary is pure ASCII, the byte count equals the character count, so 255 bytes is also 255 characters. Each unit has a generous ceiling (for example 1,000 words or 10,000 bytes) to keep one click from generating an unmanageable wall of text; the live counter under the output confirms the word, character, and paragraph totals of what you generated.
**Q: What is the difference between Lorem Ipsum, dummy text, and placeholder text?**
A: In everyday use the three terms are interchangeable — they all mean filler content that stands in for real copy while a design is built. "Lorem Ipsum" names the specific pseudo-Latin text that became the industry standard; "placeholder text" and "dummy text" are the generic categories that Lorem Ipsum belongs to. Placeholder text can also include other styles, such as themed variants (Bacon Ipsum, Hipster Ipsum) or simple repeated strings, but Lorem Ipsum remains the default because its neutral, language-agnostic look doesn't tempt reviewers to read it. When a designer asks for "some dummy text," Lorem Ipsum is almost always what they mean.
**Q: Will using Lorem Ipsum hurt my SEO or get my page penalized?**
A: Lorem Ipsum is fine during development but should never ship to a live, indexable page. It carries no penalty by itself, but if Google crawls a published page full of placeholder text, that page has no real content to rank and may be treated as thin or unfinished — wasting crawl budget and confusing users who land on it. The risk is accidental publication: a staging template, a forgotten footer, or a CMS default that goes live with Lorem still in it. Use the generator freely while building, then replace every block with real copy before launch, and search-and-replace "Lorem ipsum" across your project as a final pre-deploy check.
**Q: Does the generated text repeat, and is it the same every time?**
A: Each generation draws words at random from the classic Lorem vocabulary, so two blocks at the same settings will differ — that is what the Regenerate button is for when you want several distinct samples of the same length. With the "Start with Lorem ipsum…" toggle on, every block begins with the same canonical first line and then diverges. The randomness is purely in your browser and is not cryptographic; it exists only to make the filler look natural, with varied sentence lengths and an occasional comma, rather than mechanically repetitive.
**Q: Can I use the generated Lorem Ipsum in commercial projects?**
A: Yes, without restriction. Lorem Ipsum is not copyrighted — it is mangled Latin in the public domain — and the text this tool produces comes with no license, attribution, or usage terms. Paste it into client work, commercial products, paid templates, or anything else. The only caveat is the universal one: it is placeholder text, so replace it with real content before the project ships to real users. Nobody owns Lorem Ipsum, and nothing about generating it here creates an obligation to anyone.
---
### Markdown to HTML Converter
URL: https://go-tools.org/tools/markdown-to-html
Convert Markdown to HTML in your browser — full GitHub Flavored Markdown, live preview, syntax highlighting. Export an HTML fragment, full document, or email-safe inline-styled HTML. 100% private, no upload.
#### What is Markdown to HTML Conversion?
Markdown to HTML conversion turns a plain-text document written in Markdown — with `#` for headings, `**bold**`, `- ` for lists, and `[text](url)` for links — into the HTML that browsers, content management systems, and email clients actually display. Markdown is designed to be readable as-is and easy to write, but a browser does not understand `# Heading`; it understands <h1>Heading</h1>. Conversion bridges that gap.
Under the hood, a Markdown processor first parses your source into an abstract syntax tree (AST) — a structured representation where a heading, a paragraph, a list, and a code block are distinct nodes with their content and attributes. It then serialises that tree to HTML, emitting the correct tags and nesting. Working through an AST, rather than swapping text with regular expressions, is what lets the converter handle nested lists, tables, and embedded HTML correctly and predictably. The two recognised grammars are CommonMark, the precise standard, and GitHub Flavored Markdown (GFM), which extends it with tables, task lists, strikethrough, and autolinks.
The reason you convert at all is that almost every publishing destination wants HTML, not Markdown. A static-site generator, a CMS rich-text field, an email template, and a browser tab all render HTML. So the typical workflow is to write in comfortable Markdown — a README, documentation, a blog draft, notes — and convert to HTML at the point of publishing. This tool does that conversion locally and shows a live preview, so you see the rendered result and can copy the exact HTML in the shape you need: a fragment, a full page, or email-ready inline-styled markup.
The reverse operation — HTML back to Markdown — is equally useful when you are migrating existing web content into a Markdown-based system. For that, switch to the HTML → Markdown tab or open the dedicated HTML to Markdown converter.
```
Markdown in:
# Release Notes
We shipped **tables** and `code`:
| Feature | Status |
| ------- | ------ |
| GFM | Done |
- [x] Parse to an AST
- [ ] Profit
HTML out:
Release Notes
We shipped tables and
code:Feature Status GFM Done - Parse to an AST
- Profit
const hash = await crypto.subtle.digest('SHA-256', new TextEncoder().encode('text'));Note that Web Crypto does not support MD5 natively — use a library like 'crypto-js' or a pure JS implementation. In Python:import hashlib; hashlib.md5('text'.encode()).hexdigest(). In Node.js:require('crypto').createHash('md5').update('text').digest('hex'). Or simply use this tool for quick one-off hash generation without writing code. **Q: I need to verify a file download hasn't been corrupted — should I use MD5 or SHA-256 for the checksum?** A: Use SHA-256 whenever the publisher provides it. SHA-256 (256-bit) is the current standard for file integrity verification and is used by major software distributors including Ubuntu, Debian, and most security-conscious projects. MD5 is still widely published alongside downloads for historical reasons, and it remains adequate for detecting accidental corruption (a file being garbled during transfer). However, MD5 checksums cannot protect against a malicious actor who deliberately tampers with both the file and its checksum, since MD5 collisions can be crafted in seconds. SHA-256 closes this gap. If the publisher only provides MD5, use it — any checksum is better than none for catching download corruption. Use the File tab in this tool to compute either hash directly in your browser. **Q: My legacy system stores passwords as MD5 hashes — how do I migrate to bcrypt without forcing all users to reset?** A: Use a double-hashing migration strategy. The idea: hash each user's existing MD5 hash with bcrypt. When a user logs in, you first MD5 their submitted password (getting the old hash format), then verify that MD5 hash against the stored bcrypt hash. On successful login, immediately re-hash the plaintext password with bcrypt alone and update the database record. Over time, as users log in, records naturally migrate to pure bcrypt. Users who never log in remain on the transitional double-hash scheme, which is still far safer than plain MD5 since bcrypt adds salt and work factor. Set a deadline (6-12 months) after which inactive accounts on old hashes require a password reset. This approach migrates active users transparently with zero disruption, while remaining secure because the bcrypt layer protects the MD5 hashes from rainbow table attacks. **Q: I'm building a content-addressable storage system — is MD5 still safe for non-security hashing like deduplication?** A: MD5 is acceptable for content-addressable storage (CAS) and deduplication in most practical scenarios, with caveats. For detecting accidental duplicates — two files that happen to have identical content — MD5's 128-bit output provides a vanishingly small false-positive rate (1 in 2^128). MD5's weakness is crafted collisions: an attacker can deliberately create two different files that share the same MD5 hash. If your CAS system is purely internal and adversaries cannot inject content, MD5 is fine and fast. If users can submit content (cloud storage, CDN caching, package registries), use SHA-256 to prevent hash collision attacks. Git switched from SHA-1 to SHA-256 for exactly this reason. For maximum performance with security, SHA-256 is only ~20% slower than MD5 on modern hardware with hardware acceleration, making the security upgrade almost free in practice. --- ### Open Graph & Meta Tag Generator URL: https://go-tools.org/tools/meta-tag-generator Generate Open Graph, Twitter Card & SEO meta tags with a live Google, Facebook & X preview. 100% free, in-browser, no signup — copy & paste the code. #### What are meta tags & Open Graph? Meta tags are snippets of HTML in your page's <head> that describe the page to browsers, search engines and social platforms. The classic SEO tags are the <title>, the meta description and the canonical link. Open Graph tags (og:title, og:type, og:image, og:url and friends) are a protocol, originally from Facebook, that controls the title, description and image shown when your link is shared — and almost every platform reads them, including LinkedIn, Slack, Discord, WhatsApp, Pinterest and Telegram. Twitter/X uses its own twitter:card tags but falls back to your Open Graph tags when they are missing, so a good set of OG tags plus a single twitter:card value covers every network. This generator writes all of these tags, adds optional JSON-LD structured data, and previews the result live — so you never have to hand-write them or guess how a share will look. #### FAQ **Q: What is a meta tag generator?** A: A meta tag generator builds the HTML tags that go inside your page's <head> — the <title>, meta description, canonical link, Open Graph tags for Facebook and LinkedIn, and Twitter/X Card tags. This tool generates all of them at once, shows a live preview of how your link will look on Google, Facebook, X, LinkedIn, Slack and Discord, and lets you copy the code with one click. Everything runs in your browser. **Q: How do I add Open Graph tags to my website?** A: Fill in your title, description, canonical URL and an og:image URL, choose the Open Graph type, then copy the generated tags and paste them inside the <head> of your HTML. Because Facebook, LinkedIn, WhatsApp and Telegram crawlers do not run JavaScript, the tags must be present in the server-rendered or static HTML, not injected by client-side scripts. **Q: What size should an Open Graph image be?** A: The recommended og:image size is 1200×630 pixels, a 1.91:1 aspect ratio, which also satisfies X's summary_large_image card. Facebook ignores images smaller than 200×200 and shows a small square for anything under 600×315. Always include og:image:width and og:image:height so the first share renders instantly, and serve the image over HTTPS at a public URL that is not blocked by robots.txt. **Q: Is the twitter:card tag required?** A: Yes — twitter:card is the one Twitter/X tag you must include, otherwise X will not render a card even when your Open Graph tags are present. Set it to summary_large_image for a big image or summary for a small square thumbnail. For everything else (title, description, image) X falls back to your og:* tags, so this tool leaves them out by default to keep the markup clean. **Q: Do meta tags help SEO?** A: The <title> and canonical tag matter for SEO; the meta description is not a direct ranking factor but influences click-through by shaping the search snippet. Open Graph and Twitter Card tags do not affect Google rankings, but they control how your links look when shared, which drives social traffic. Google may rewrite your title in results, so write a clear, unique one and keep the important words first. **Q: Does this tool upload my content or images?** A: No. Everything is generated locally in your browser with JavaScript. Your title, description and image URL never leave the page — there is no server, no upload and no account. The og:image is loaded only in your own browser to preview it and read its dimensions. **Q: Can I import meta tags I already have?** A: Yes. Open the Import panel, paste your existing <meta> tags, and the tool parses them locally with the browser's own HTML parser to fill in the form — no network request, nothing uploaded. It is the privacy-first alternative to tools that fetch a live URL from their server. **Q: Why does my updated preview still show the old image on Facebook or LinkedIn?** A: Platforms cache Open Graph data: Facebook for about 30 days, LinkedIn for about 7 days. After you deploy, re-scrape the page with the Facebook Sharing Debugger or LinkedIn Post Inspector to refresh the cached title, description and image. The debugger links are listed under the generated code. --- ### Nginx Location Tester — Why That Block Wins URL: https://go-tools.org/tools/nginx-location-tester See which nginx location block wins — and why every other block lost. Free location match tester for =, ^~, ~ and ~*, running entirely in your browser. #### What Is an nginx location Block? Alocationblock tells nginx what to do with a request whose URI matches a pattern. A server block usually holds several, and the interesting part is not what each one does but which one nginx picks — because the selection rules are not the ones most people assume. There are five forms.location = /pathmatches only when the whole URI is equal.location /pathmatches any URI starting with those characters.location ^~ /pathis the same prefix comparison with one extra effect.location ~ regexandlocation ~* regexapply a PCRE pattern, case-sensitively and case-insensitively.location @namenever takes part in URI matching at all and exists only as a target fortry_filesanderror_page. Selection runs in stages. First the URI is normalised: percent-decoded,.and..resolved, repeated slashes collapsed, query string split off. Then an=location equal to the URI ends the search immediately. Then every matching prefix is compared and the longest is remembered — configuration order plays no part here at all. If that remembered prefix carries^~, nginx stops and uses it. Otherwise the regex locations are tried in the order they appear in the file, and the first match wins, however specific a later one might be. If none matches, the remembered prefix is used. Two of those rules pull in opposite directions, and that is where the confusion lives: prefixes are chosen by length regardless of order, regexes by order regardless of length. A config that reads correctly from top to bottom can still route a request somewhere you did not intend, and no amount of re-reading reveals it. This page replays the whole sequence against your own config and shows where each block dropped out. ``` # From the nginx documentation. Which block serves each request? server { location = / { } # A location / { } # B location /documents/ { } # C location ^~ /images/ { } # D location ~* \.(gif|jpg|jpeg)$ { } # E } # / -> A exact match, search ends here # /index.html -> B no regex matched, longest prefix used # /documents/document.html -> C longer prefix than B # /images/1.gif -> D ^~ won the prefix stage, regex skipped # /documents/1.jpg -> E regex beats the longer prefix C # The last two lines are the whole lesson: identical-looking prefixes # behave differently because only one of them carries ^~. ``` #### FAQ **Q: How do I debug which location nginx selected?** A: Paste the config and the request URI into this tester to see the winning block and why each other block was eliminated. On a running server, adderror_log /var/log/nginx/debug.log debug;and look for the "using configuration" line, which names the selected location. The two approaches answer different questions: the log tells you what a live server did, and this page tells you what a config you have not deployed yet would do. **Q: Why is my nginx location regex not working?** A: Usually one of three reasons, and the decision table names which. An earlier regex already matched, so yours never ran — regexes are tried in file order and the first match wins. Or the longest matching prefix carries^~, which skips the regex phase completely. Or the regex is fine but the URI is not what you think: matching runs against the normalised path, after percent-decoding and..resolution, with the query string removed. **Q: Why is my exact match not triggering?** A: An=location requires the whole URI to be equal, not to start with the pattern.location = /a/does not match/a, andlocation = /adoes not match/a/b. Trailing slashes are ordinary characters here, so the two forms are different strings. When an exact location does match, the search stops immediately and nothing else is even compared. **Q: Does nginx match the query string in a location block?** A: No. The query string is split off during normalisation and location selection runs against the path alone. That is whylocation = /amatches a request for/a?x=/b. If you need to branch on a parameter you have to read$arg_nameor$argsinside the block. One subtlety worth knowing:%3Fdecodes to a literal question mark that stays in the path, so/a%3Fx=1has an empty query string and a path containing?. **Q: Can I use JavaScript regex syntax in an nginx location?** A: No — nginx uses PCRE, and the differences matter. This page runs in your browser, where only ECMAScript regular expressions exist, so PCRE-only constructs are detected and flagged rather than silently mis-evaluated: atomic groups, possessive quantifiers, inline modifiers such as(?i), POSIX classes such as[[:alpha:]], and escapes like\Aand\Kthat JavaScript quietly reads as ordinary letters. When a location is flagged, the remaining candidates are still evaluated in nginx's order, but that block's verdict needs checking on a real server. If you are writing the pattern itself, the regex tester covers ECMAScript syntax in depth. **Q: Are nginx location prefix matches case-sensitive?** A: On Linux, yes —location /Static/does not match/static/x. On case-insensitive filesystems such as macOS and Cygwin, nginx compares prefixes case-insensitively and additionally forces every regex location to behave like~*. This page models the Linux behaviour, which is what production servers almost always run. If you develop on a Mac and deploy to Linux, that difference can hide a broken rule until it ships. **Q: Does try_files change which location block was selected?** A: No. Location selection finishes first;try_filesruns afterwards, inside whichever block already won. If a request never reaches the block containing yourtry_files, the directive is irrelevant — the usual cause is a~ \.php$regex taking the request before the prefix block with the fallback ever gets to act. An internal redirect issued later does restart matching, so a rewritten URI is resolved against the location list again from the top. **Q: Why does nginx return 301 when I request a directory without a slash?** A: Two different mechanisms produce that. If a location whose name ends in/carriesproxy_passor another*_passdirective, a request for the same path without the slash is answered with a 301 during location selection — before any regex is evaluated. Separately, the static file module issues a 301 when the path resolves to a real directory on disk. The first is visible here; the second depends on your filesystem. Addinglocation = /pathsuppresses the first. **Q: Do nested location blocks change the outcome?** A: Yes, and in a way that is easy to miss. nginx descends into the winning prefix location and searches its children, so a nested regex is tried before the parent level's regexes. A^~on the outer block does not shield it from its own nested regexes, and nesting can make a globally longer prefix unreachable when a sibling at the outer level wins first. Nested blocks are modelled here with the same indentation you wrote them in. **Q: Is my nginx configuration uploaded anywhere?** A: No. Parsing and matching happen locally in your browser with plain string operations — there is no server call and nothing is retained. This matters more here than for most tools, because a real server block contains upstream hostnames, internal ports, certificate paths and auth rules. You do not have to take our word for it: open your browser's developer tools and watch the Network panel stay silent while you type, or disconnect entirely and keep testing. The absence of any external request is also enforced by an automated contract test on every build, so it cannot quietly regress. --- ### PX to REM Converter — Convert Pixels to Rem URL: https://go-tools.org/tools/px-to-rem Convert px to rem instantly. 16px = 1rem at the default base, plus any custom root font-size. Free, live two-way conversion that runs 100% in your browser. #### What Is a PX to REM Converter? A px to rem converter translates pixel measurements into rem units for CSS. The rem ("root em") unit is relative to the font-size of the root element: 1rem always equals the root font-size, which browsers set to 16px by default. The conversion is a simple division — rem = px ÷ root-font-size — but doing it by hand for every font size, margin, and breakpoint in a stylesheet is tedious and error-prone, which is what this tool removes. The reason to convert at all is accessibility and scalability. When a value is written in px, it is locked to a fixed size and ignores the user's browser font-size preference. When it is written in rem, it scales proportionally if the user increases their default font size — a critical accommodation for people with low vision and a smoother experience for everyone who zooms. Expressing a design system in rem also means a single change to the root font-size rescales the entire interface consistently. This converter keeps both the pixel and rem fields linked in real time, so you can move in either direction, and — unlike tools that hard-code a 16px base — it lets you set any root font-size. That matters because a stylesheet using the 62.5% technique (a 10px root) converts differently from a default 16px setup. A live preview shows the resulting text size, and a reference table lists the most common px values at a 16px base for quick lookups. Need the reverse direction? Use the rem to px converter. For tidying up the stylesheet itself, try the CSS formatter, and for color work see the color converter. Everything runs in your browser — your values never leave your device. ``` /* The core formula */ /* rem = px ÷ root-font-size (16px by default) */ :root { font-size: 16px; /* 1rem = 16px */ } .title { font-size: 1.5rem; } /* 24px */ .body { font-size: 1rem; } /* 16px */ .caption{ font-size: 0.75rem; } /* 12px */ .card { padding: 1.5rem; } /* 24px */ /* JavaScript equivalent */ const pxToRem = (px, base = 16) => px / base; console.log(pxToRem(24)); // 1.5 console.log(pxToRem(12)); // 0.75 ``` #### FAQ **Q: What is 16px in rem?** A: 16px equals exactly 1rem when the root font-size is the browser default of 16px. The rem unit is relative to the font-size of the root element, so rem = px ÷ root-font-size. Because most browsers default to 16px, 16px is the natural anchor: 16px = 1rem, 8px = 0.5rem, 32px = 2rem. If you change the root font-size, the ratio changes accordingly. **Q: How do you convert px to rem?** A: To convert px to rem, divide the pixel value by the root font-size (16px by default). The formula is rem = px ÷ base. For example, 24px ÷ 16 = 1.5rem, and 12px ÷ 16 = 0.75rem. This tool does the division for you in real time and lets you change the base if your project uses a different root font-size. **Q: What is 1rem in pixels?** A: 1rem equals the root font-size in pixels — 16px by default. So 1rem = 16px, 1.5rem = 24px, and 2rem = 32px on a standard setup. If you set html { font-size: 62.5% } (10px), then 1rem = 10px instead. To go from rem back to pixels, multiply: px = rem × base. **Q: Why use rem instead of px?** A: Rem units respect the user's browser font-size preference, which is essential for accessibility. When someone increases their default font size — for low vision or simply comfort — everything sized in rem scales proportionally, while px values stay fixed and can break layouts or ignore the preference. Rem also keeps a design system consistent: change one root font-size and the whole interface scales together. Pixels are still useful for things that should not scale, such as 1px borders. **Q: What is the difference between px, rem, and em?** A: px is an absolute unit — one CSS pixel, fixed regardless of context. rem is relative to the root () font-size, so it is consistent everywhere on the page. em is relative to the font-size of the current element's parent, so it compounds when nested. Use px for fixed details like hairline borders, rem for most sizing so it scales with the user's preference, and em when you want a value to scale relative to its local context (for example padding that grows with a button's own font size). **Q: What is the 62.5% font-size trick?** A: Setting html { font-size: 62.5% } makes the root font-size 10px (because 62.5% of the 16px default is 10px). With a 10px base, rem math becomes trivial: 1rem = 10px, 1.6rem = 16px, 2.4rem = 24px — just divide the pixel value by 10. Many developers like the simpler arithmetic, though you then typically set body { font-size: 1.6rem } to restore readable 16px body text. Set this tool's root font-size to 10 to convert against the 62.5% base. **Q: Can I change the root font-size in this converter?** A: Yes. The Root font-size field defaults to 16px (the browser default) but you can type any value — 10, 18, 20, or whatever your project uses. Every conversion and the reference table update against the base you set. Click 'Reset to 16' to return to the default. Most tools hard-code 16px; the custom base is what lets this converter match your real stylesheet. **Q: Is 16px always equal to 1rem?** A: Only when the root font-size is 16px, which is the default in virtually all browsers. The relationship 16px = 1rem holds as long as you do not override html { font-size }. If a stylesheet sets the root font-size to something else — say 10px or 18px — then 16px no longer equals 1rem. Always convert against the actual root font-size of the page. **Q: Should I convert font sizes, padding, and margins to rem?** A: Font sizes are the strongest candidates for rem because they directly affect readability and accessibility. Padding, margin, gap, and border-radius are also commonly expressed in rem so spacing scales together with text for a cohesive layout. Media-query breakpoints in rem (or em) zoom more gracefully. Keep px for things that must not scale, like 1px borders and some box-shadow offsets. **Q: Does converting px to rem change how my site looks?** A: No — at the default 16px root font-size, a value in rem renders at exactly the same pixel size as the original px value. 24px and 1.5rem look identical on a standard setup. The difference is behavioral: the rem version will scale if the user changes their browser font size, whereas the px version will not. Visually nothing changes until the user adjusts their preferences. **Q: How accurate is this px to rem converter?** A: Conversions use IEEE 754 double-precision arithmetic and the exact formula rem = px ÷ base, with results rounded to at most five decimal places and trailing zeros trimmed for readability. For CSS that precision is far finer than the browser needs. The math is deterministic and runs the same every time, so you can rely on it for production stylesheets. **Q: Is my data safe when using this converter?** A: Completely. All conversions run locally in your browser using JavaScript. No values are sent to any server — there are no network requests, no cookies on your input, and no analytics tied to what you type. You can verify this by disconnecting from the internet: the tool keeps working fully offline once the page has loaded. --- ### Q-Format Fixed-Point Converter URL: https://go-tools.org/tools/q-format-converter Convert Q7, Q15, Q31, Q1.15, and Q16.16 values between decimal, raw integer, hex, and binary. Inspect exact stored values, quantization error, rounding, and overflow locally. #### What is Q-format fixed point? Q-format stores a real value as an integer plus an implied binary scale. For a word with F fractional bits, stored integer N represents N / 2^F; the point is not physically stored in the word. A signed word normally uses W-bit two's complement, while an unsigned word uses the full code range. This makes multiplication, filtering, and register storage predictable on hardware without floating-point support, but it also makes range, rounding, saturation, and notation part of the data contract. Q labels are not completely standardized, so this converter treats signedness, total width W, and fractional bits F as the canonical definition and displays them beside every result. #### FAQ **Q: What does Q15 mean?** A: In the common DSP convention used by this tool, Q15 is a signed 16-bit two's-complement word with 15 fractional bits: one sign/integer position and 15 fraction positions. Its scale is 2^15, resolution is 1/32768, and range is -1 through 32767/32768. Some documents use Qm.n differently, so verify the total width and signedness instead of relying on the label alone. **Q: Are Q15 and Q1.15 the same?** A: They often refer to the same signed 16-bit layout, but Q notation is not universal. Some authors count the sign bit inside the integer count and others do not. This converter resolves the ambiguity by always showing signedness, total bits W, fractional bits F, and scale 2^F; its Q15 and Q1.15 preset is signed W=16, F=15. **Q: How is a negative hexadecimal Q-format word decoded?** A: First parse the hexadecimal text as an unsigned W-bit raw code. If the format is signed and the top bit is set, subtract 2^W to obtain the two's-complement stored integer. Then divide that integer by 2^F. For signed Q15, 0xC000 becomes 49152 - 65536 = -16384, then -16384 / 32768 = -0.5. **Q: Which rounding and overflow modes are supported?** A: Decimal encoding supports round to nearest with ties to even, truncate toward zero, and floor toward negative infinity. If the rounded integer is outside the W-bit range, Error rejects it, Saturate clamps to the nearest endpoint, and Wrap applies modulo 2^W. Raw hex and binary decoding does not round because the stored word is already exact. **Q: When should I use Q-format instead of IEEE 754?** A: Use Q-format when a protocol, DSP algorithm, register, or embedded system defines a fixed binary scale for an integer word. Use IEEE 754 floating-point when the word contains a sign, dynamic exponent, and significand. For plain integer radix changes without a scale or signed width, use the number base converter. **Q: Does this converter upload my values or hex dump?** A: No. Parsing, BigInt arithmetic, rounding, overflow handling, and batch decoding run locally in your browser. The batch input is bounded to 16 KiB and 256 words for responsive use, and entered numeric values are not included in analytics events. --- ### Online QR Code Decoder URL: https://go-tools.org/tools/qr-code-decoder Decode a QR code from an image or screenshot by choosing, dropping or pasting it. Review the encoded URL and hostname before opening a link; the image stays in your browser and is never sent to a server. #### What is an online QR code decoder? An online QR code decoder reads the square QR symbol inside an existing image or same-device screenshot and reveals the encoded payload without requiring a second phone. This page accepts a chosen, dropped or pasted image, decodes it locally, and organizes recognized URL, WiFi, vCard, email, SMS and geo fields while retaining the original text. It reads one QR result rather than generic barcodes or a live camera feed. After reviewing the result, you can copy it to the QR code generator to create a replacement code. #### FAQ **Q: Are QR code images uploaded?** A: No. The selected image is decoded in your browser and is not sent to an upload endpoint. This local processing includes potentially sensitive screenshots and WiFi payloads. **Q: Which image formats and sizes work?** A: The input accepts PNG, JPEG, WebP and GIF files up to 10 MiB. For GIF files, only the first frame is examined, so move the code to the first frame or save a still image when needed. **Q: Can it scan with my camera or read barcodes?** A: No. This tool reads one QR code from an image you choose, drop or paste. It does not access a camera and it is not a generic barcode reader. **Q: Why does a clear QR still fail to decode?** A: The code may be too small, blurred, cropped through its quiet zone, strongly tilted, low contrast or outside the first GIF frame. Try a sharper crop that keeps a margin around the entire square. No decoder can guarantee every damaged image will scan. **Q: Do link warnings mean a site is malicious?** A: No. HTTPS, HTTP, credential-like URLs, punycode and IP-address notices are explainable cues derived from the text itself. The decoder performs no reputation lookup, so a warning is not a verdict and no warning is a safety guarantee. **Q: Can I turn the decoded content into a new QR code?** A: Yes. Copy the decoded payload and continue to the QR code generator. Review the copied content first, especially passwords, contact data and destinations. --- ### QR Code Generator — URL, WiFi, vCard, Email, SMS, Geo URL: https://go-tools.org/tools/qr-code-generator Free QR code generator. Make static QR codes for URL, WiFi, vCard, email & SMS. SVG & PNG download. No expiration, no signup, 100% in your browser. #### What is a QR Code? A QR Code (Quick Response Code) is a 2D matrix barcode invented by Denso Wave in 1994 and codified by ISO/IEC 18004:2015. It encodes data into a square grid of black and white modules, with three large finder patterns at the corners that let scanners locate and orient the code. Versions range from 1 (21×21 modules) to 40 (177×177); the encoder picks the smallest version that fits your content at the chosen error correction level. QR codes carry many data types via standard URI schemes. URLs are encoded directly. WiFi credentials use the de facto WIFI: protocol that iOS Camera (since iOS 11) and Android camera apps recognize natively. Contact cards use vCard 3.0 (RFC 2426) — broader scanner compatibility than vCard 4.0 (RFC 6350). Email links use mailto: (RFC 6068), text messages use sms: (RFC 5724), and map pins use geo: (RFC 5870). Scanning a well-formed QR triggers the right action — open URL, join WiFi, save contact, draft email — without the user typing anything. Reed-Solomon error correction is what keeps QR codes scannable when they're scratched, folded, or partly obscured. Four levels — L, M, Q, H — recover roughly 7%, 15%, 25%, and 30% of damaged data. Higher levels add redundancy modules, so the QR grows physically larger for the same content. Choose H for printed materials that will be handled, M for screens, L only when you're squeezing in long URLs. The biggest practical distinction is static vs dynamic. A static QR encodes your real content directly into the pixels — it works forever, with no service to maintain. A dynamic QR encodes a short link to a third-party redirect service; if that service expires, raises its price, or shuts down, every printed QR you've shipped goes dead. Read Static vs Dynamic QR Codes — why yours stops working for the full story. This tool generates static QRs only. Many online QR generators upload your WiFi password, vCard contact details, or private URL to their server before encoding. This tool runs the qrcode npm library entirely in your browser — zero uploads, zero logs, zero tracking. It's the same privacy posture as our other client-side encoders Base64 Encoder/Decoder and URL Decoder/Encoder: your inputs never leave the page. ``` // Build a WiFi payload and generate an SVG QR import QRCode from 'qrcode'; // 1. WIFI: protocol (de facto, recognized by iOS+Android) const payload = 'WIFI:T:WPA;S:My\\;Network;P:p@ss\\;word;H:false;;'; // 2. Generate SVG (vector, scales without pixelation) const svg = await QRCode.toString(payload, { type: 'svg', errorCorrectionLevel: 'M', margin: 4, color: { dark: '#000000', light: '#ffffff' }, }); // 3. Drop into the DOM (DOMParser-safe, not innerHTML) const doc = new DOMParser().parseFromString(svg, 'image/svg+xml'); preview.replaceChildren(doc.documentElement); ``` #### FAQ **Q: Why does my QR code stop working after a while?** A: Because it's a dynamic QR — the QR encodes a short tracking URL that redirects to your real content. When the redirect service expires, raises its price, or shuts down, the QR is dead. This tool generates static QR codes that encode your data directly into the pixels. They never expire. Read the full guide. **Q: Will this QR code expire?** A: No. We generate static QR codes. Your URL, text, WiFi, or vCard data is encoded directly into the QR pixels — there is no redirect, no service to maintain, no subscription. As long as the printed or saved QR is intact, it will scan forever. **Q: How do I create a WiFi QR code?** A: Switch to the WiFi tab, enter your SSID (network name) and password, then pick the security type — WPA / WPA2 / WPA3 for almost all modern networks, WEP for legacy gear, or No password for open networks. Tick Hidden network if your SSID is not broadcast. Download the QR — guests scan it with their phone camera and join automatically. **Q: How do I make a vCard QR code for my business card?** A: Switch to the vCard tab and fill name, phone, email, organization, and website. Output is vCard 3.0 (RFC 2426) — the format both iOS and Android recognize most reliably (vCard 4.0 / RFC 6350 has worse scanner support). Print the QR on paper cards; scanning offers to save the contact in one tap. **Q: Is this QR code generator free?** A: Yes — no signup, no payment, no usage limits, no watermark on the output. The site is supported by minimal display ads on unrelated pages. The tool itself runs entirely in your browser with no upload and no tracking. **Q: Can I download QR codes as SVG?** A: Yes — SVG is the default download format. SVG is vector, so it scales to any size without pixelation, and you can paste it directly into Figma, Illustrator, Sketch, or send it to a printer at billboard size. Need a raster file instead? Pick PNG at 256, 512, or 1024 px from the Download menu. **Q: What is the maximum length of data a QR code can hold?** A: Up to ~2,953 bytes for byte mode at error correction level L (Version 40 QR), ~2,331 at level M, ~1,663 at Q, ~1,273 at H. Numeric-only data fits more (up to 7,089 digits at L). If your content is rejected, lower the error correction level or shorten the URL. **Q: What error correction level should I use?** A: M (medium, ~15% recovery) is the default and works for most cases. Use H (~30%) if the QR will be printed on packaging, fabric, or anywhere damage is likely. Use L (~7%) only if you are hitting the byte limit and the QR will live on a screen rather than in print. **Q: Can I add a logo to the QR code?** A: Not yet. Logo embedding works best with a higher error correction level (Q or H) and careful sizing — otherwise the QR becomes unreliable across phones. We are evaluating it for v2 with safe defaults. For now we recommend keeping the QR clean: the highest-converting QRs are the simplest. **Q: Are my inputs uploaded to a server?** A: No. All QR generation happens in your browser using the qrcode npm library, loaded once and run locally. Your URL, WiFi password, vCard data, and any other input never leave your device. Refreshing the page clears all inputs. We do not store, log, or analyze what you generate. **Q: Why is my custom-colored QR not scanning?** A: QR scanners need high contrast between foreground (dark) and background (light). If you reverse them — light foreground on a dark background — most scanners fail. Stick to dark on light with a contrast ratio of at least 4.5:1. This tool warns you when contrast is too low. **Q: What QR code version is generated?** A: The qrcode library auto-selects the smallest QR version (1 to 40) that fits your content at the chosen error correction level. Version 1 is 21×21 modules; Version 40 is 177×177. The output follows ISO/IEC 18004:2015, the international QR Code standard. **Q: Can I use this QR code for commercial purposes?** A: Yes — QR Code is an open standard (ISO/IEC 18004) and not restricted by patents (Denso Wave released the patent rights in 1994). The QR codes you generate here are yours to use commercially without attribution or license fees. **Q: Does this work offline?** A: After the first load, the qrcode library is cached by your browser, so subsequent generations work without network access. The page itself is statically served — no API calls, no backend dependencies. Open it once on a flight and generate QRs at 30,000 ft. **Q: How do I read a QR code that is already in an image?** A: Open the QR code decoder for images, then upload the image, drag and drop it, or paste it from your clipboard. The image is processed locally in your browser and is not sent to a server. --- ### Random Password Generator — Customizable, Strong & Secure URL: https://go-tools.org/tools/random-password-generator Generate strong random passwords instantly — free, 100% in your browser. Customize length & characters, batch up to 50 with entropy analysis. #### What Is a Random Password Generator? A random password generator creates cryptographically secure passwords using unpredictable random data, making each generated password resistant to brute-force and dictionary attacks. Unlike passwords invented by humans, generated passwords carry no patterns, no dictionary words, and no personal information — the three properties most exploited by attackers. Over 80% of data breaches involve weak or stolen passwords (Verizon DBIR), making strong password generation a first-line defense. "Memorized secrets SHALL be at least 8 characters in length... Verifiers SHOULD NOT impose other composition rules." — NIST SP 800-63B This tool uses your browser's built-in Web Crypto API (crypto.getRandomValues()) to produce true cryptographic randomness. Every character is independently selected from your chosen character pool, ensuring uniform distribution and maximum entropy. Need a unique identifier instead? Try our UUID Generator. Why does this matter? A 16-character password using all character types (uppercase, lowercase, digits, symbols) has over 100 bits of entropy. At a rate of one trillion guesses per second, it would take billions of years to brute-force. A human-chosen password of the same length typically has far less entropy because people unconsciously follow patterns. Learn how password entropy works. All password generation happens entirely in your browser. No passwords are transmitted over the network, stored on any server, or logged anywhere. You can verify this by checking your browser's Network tab — there are zero outgoing requests when you generate a password. If you need to encode generated passwords for safe transport, our Base64 Encoder can help. For a comprehensive look at password hashing, authentication, and other security fundamentals, read our web security best practices guide. ``` // Generate a random password in JavaScript (unbiased via rejection sampling) // `v % charset.length` is biased whenever 2^32 isn't a multiple of charset.length. // We discard out-of-range draws so every character is uniformly distributed. function unbiasedIndex(modulus) { const limit = Math.floor(0x100000000 / modulus) * modulus; const buf = new Uint32Array(1); let v; do { crypto.getRandomValues(buf); v = buf[0]; } while (v >= limit); return v % modulus; } function generatePassword(length, charset) { let out = ''; for (let i = 0; i < length; i++) out += charset[unbiasedIndex(charset.length)]; return out; } // Example: 16-char password with all types const chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*'; generatePassword(16, chars); // → 'kX#9mP$2vL!nQ7wR' (random each time) ``` #### FAQ **Q: Is it safe to use an online password generator?** A: Yes, this online password generator is safe. Every password is created entirely in your browser using JavaScript and the Web Crypto API — no data is ever sent to a server. You can verify this yourself by opening your browser's Developer Tools (F12 → Network tab) while generating passwords: you'll see zero outgoing requests. Because nothing leaves your device, there is no risk of interception or server-side leaks. This is the same local-generation approach used by reputable password managers like Bitwarden and 1Password. All our tools, including the UUID Generator and Base64 Encoder, run 100% in the browser. **Q: What makes a strong password?** A: A strong password is long, random, and unique. Length matters more than complexity — a 16-character password is exponentially harder to crack than an 8-character one, regardless of character mix. That said, using a combination of uppercase letters, lowercase letters, digits, and symbols maximizes the number of possible combinations. Avoid dictionary words, names, dates, and keyboard patterns like 'qwerty'. Most importantly, never reuse a password across multiple accounts. Use a random password generator to eliminate human bias entirely. **Q: How long should my password be?** A: In 2026, the recommended minimum password length is 12 characters, but 16 characters is the sweet spot for most accounts. For high-security accounts like banking, primary email, or cloud administration, use 20 to 32 characters. A 16-character password with all character types has about 105 bits of entropy, which would take billions of years to brute-force at one trillion guesses per second. Each additional character multiplies the number of possible combinations, so longer is always better. **Q: Is an 8-character password secure enough?** A: No, an 8-character password is no longer considered secure. Even with a full mix of uppercase, lowercase, digits, and symbols, an 8-character password has only about 52 bits of entropy and can be cracked in hours to days by modern hardware. By contrast, a 12-character password takes centuries and a 16-character password takes billions of years. Security experts and NIST recommend a minimum of 12 characters. We recommend 16 characters for everyday accounts and 20 or more for sensitive ones. **Q: Random password vs. passphrase — which is more secure?** A: Both can be highly secure, but they excel in different areas. A random password like 'kX#9mP$2vL!nQ7wR' packs maximum entropy into fewer characters, making it ideal when length is limited. A passphrase like 'correct-horse-battery-staple' is easier to remember and type but needs to be longer (4 to 6 random words) to achieve equivalent strength. For accounts stored in a password manager, random passwords are the best choice since you don't need to memorize them. For your password manager's master password, a long passphrase is often more practical. **Q: Should I include symbols in my password?** A: Yes, including symbols is recommended whenever the service allows it. Adding symbols like !@#$%^&* expands the character pool from 62 (letters and digits) to over 90 characters, which significantly increases entropy. A 16-character password with symbols has about 105 bits of entropy compared to about 95 bits without them. If a website restricts certain special characters, simply increase your password length by 2 to 4 characters to compensate for the smaller character pool. **Q: How do I remember randomly generated passwords?** A: The short answer: don't try to memorize them. Instead, use a password manager like Bitwarden, 1Password, or KeePass to store all your passwords securely. You only need to remember one strong master password or passphrase to unlock your vault. Your password manager auto-fills credentials on websites and apps, so you never need to type random passwords manually. This approach lets you use a unique, complex password for every account without any memory burden. **Q: Why shouldn't I use the same password for every account?** A: Reusing passwords is one of the biggest security risks online. When a company suffers a data breach — and breaches happen constantly — attackers use stolen credentials to try logging into other services. This is called credential stuffing, and it works because most people reuse passwords. If your one password is exposed, every account sharing that password is compromised. Using a unique random password for each account means a single breach stays contained to that one service. **Q: How often should I change my passwords?** A: According to current NIST guidelines (SP 800-63B), you do not need to change passwords on a fixed schedule if they are strong and unique. Forced periodic changes often lead to weaker passwords because people make minimal, predictable modifications. Instead, change a password immediately if you suspect it has been compromised, if a service reports a data breach, or if you've been sharing it. The best strategy is to use a strong random password with a password manager and only rotate when there's a specific reason. **Q: What are 'ambiguous characters' and why exclude them?** A: Ambiguous characters are visually similar pairs that are easy to confuse: 0 (zero) vs O (letter O), l (lowercase L) vs 1 (digit one), and I (uppercase i) vs l (lowercase L). Excluding them makes passwords easier to read, type, and communicate verbally without errors. This is especially useful for temporary passwords shared with others or passwords you need to enter on mobile devices. The slight reduction in the character pool is negligible for security — a 16-character password without ambiguous characters still has about 97 bits of entropy. **Q: How long should my passwords be in 2026 — is 12 characters still enough?** A: In 2026, 12 characters is the absolute minimum, but 16 characters is the recommended default for most accounts. NIST SP 800-63B (updated 2024) sets 8 characters as the floor but security practitioners widely recommend 16+. The reason: GPU-accelerated cracking rigs can now exhaust all 12-character passwords using only lowercase and uppercase letters in under a day. With all character types (94 characters), a 12-character password has about 79 bits of entropy — adequate but not comfortable. A 16-character password with all types reaches ~105 bits and would take billions of years to crack at one trillion guesses per second. For high-value accounts (banking, email, cloud admin), use 20-32 characters. Always pair length with uniqueness — a unique 12-character password beats a reused 32-character one every time. **Q: I need to generate API keys for my SaaS product — should I use a password generator or something else?** A: For API keys, a password generator works but isn't the ideal tool. API keys need specific properties: high entropy (256+ bits), URL-safe characters (no + or /), a fixed recognizable format, and often a prefix for quick identification (like sk_live_ or ghp_). The best approach is to generate 32 bytes of cryptographically random data and encode them as Base64URL or hex, giving you 256 bits of entropy in a compact string. In Node.js: crypto.randomBytes(32).toString('base64url'). In Python: secrets.token_urlsafe(32). If you use this password generator, set the length to 43+ characters with alphanumeric-only characters (no symbols that require URL encoding). Always prefix API keys with your product name so users can identify them in .env files and secret managers. **Q: My company requires passwords with uppercase, lowercase, numbers and symbols — but I heard NIST says that's unnecessary. Who's right?** A: Both positions have merit, but they're addressing different problems. NIST SP 800-63B (2024) discourages mandatory composition rules like "must contain uppercase, lowercase, number, symbol" because they lead to predictable patterns (Password1! is technically compliant but weak) and make passwords harder to remember, causing people to reuse them. NIST instead recommends focusing on length and checking passwords against known-breached lists. However, when you're using a random password generator stored in a password manager, composition requirements are irrelevant — the generator picks all character types optimally. The NIST guidance targets human-chosen passwords, not machine-generated ones. For generated passwords in a manager, using all character types is still strictly better because it increases the entropy per character. So: your company's policy is suboptimal for human passwords but fine for generated ones. --- ### Free Regex Tester — Debug & Match Patterns Online URL: https://go-tools.org/tools/regex-tester Test regex patterns instantly against any text. Live match highlighting, capture groups, replace preview, split, and pattern explainer. JavaScript-flavor regex, 100% private, no signup. #### What is a regex tester? A regex tester (regular expression tester) is a tool that lets you write a regex pattern, paste a piece of test text, and see exactly what the pattern matches — with capture groups, replacement preview, and a flag breakdown — without recompiling code or running a script. For developers, it shortens the loop from minutes to milliseconds: tweak the pattern, watch the highlights move, ship the regex with confidence. A regular expression is a compact language for describing text patterns. `\d+` matches one or more digits. `[A-Za-z_]\w*` matches a typical identifier. `(?\d{4})-(? \d{2})-(? \d{2})` matches an ISO date and names each part. Regular expressions are the backbone of search-and-replace in every code editor, of validation in every form, of log parsing in every observability stack, and of `grep`, `sed`, and `awk` — the Unix tools half the internet runs on. They're also notoriously hard to write correctly: an off-by-one quantifier or a missing escape can match the wrong substring, miss a match entirely, or — worst case — trigger catastrophic backtracking that takes a CPU core hostage. A good regex tester catches each of those failure modes before they reach production. This tester runs the native ECMA-262 RegExp engine that ships in every modern browser — the same engine you call from JavaScript, TypeScript, Node.js, Deno, or Bun. That means: capture groups (numbered and named with `(? ...)`), lookahead and lookbehind assertions (`(?=...)`, `(?!...)`, `(?<=...)`, `(? template alphabet — exactly what JavaScript's String.replace accepts. The Split tab applies String.split with the regex and shows each part. The Explain tab tokenises the pattern and annotates each piece in plain English, useful for code review, teaching, and porting between dialects. For privacy: every operation is local. Your pattern and your test text never leave the page — they aren't logged, aren't sent to an analytics service, aren't stored on disk. Only your UI preferences (active tab + which flags you usually have on) persist to localStorage. That makes this tool safe for redacted log samples, proprietary patterns, internal config, and patterns that include hints about your data schema. Compared to server-backed testers like regex101, the privacy and latency story is strictly better; the trade-off is single-flavor support (JavaScript only). If you're new to regex, the Common patterns dropdown ships with battle-tested starters: email address, URL, IPv4, UUID, hex color, ISO date, US phone number, and a trim-trailing-whitespace pattern. Load one, observe the matches against the supplied sample text, then mutate the pattern one character at a time to feel how the engine responds. Pair this with the Text Diff tool when you want to compare before/after of a regex-driven cleanup, with JSON Formatter when your input or expected output is JSON, or with URL encoder when the strings you match are URL-encoded. ``` // The pattern you build in this tester drops straight into JavaScript. // Example: extract every ISO date from a string with named groups. const pattern = /(? \d{4})-(? \d{2})-(? \d{2})/g; const text = 'shipped 2026-05-21, scheduled 2026-06-30'; for (const m of text.matchAll(pattern)) { console.log(m.groups.year, m.groups.month, m.groups.day); // → 2026 05 21 // → 2026 06 30 } // Same regex, used in a replace with $ templates: text.replace(pattern, '$ /$ /$ '); // → 'shipped 21/05/2026, scheduled 30/06/2026' // With the /d flag, every match carries [start, end] indices // per capture group — the Matches panel uses this to paint offsets. const p2 = /(? \d{4})-(? \d{2})/gd; const m = [...text.matchAll(p2)][0]; m.indices.groups.year; // [8, 12] ``` #### FAQ **Q: Is my regex or test text sent to your server?** A: No. Every match, replace, split, and explain operation runs in JavaScript inside your browser using the native RegExp engine. Your pattern and text are not uploaded, not logged, not stored on disk, not sent to any third party. Only your UI preferences (active tab + which flags you usually have on) are saved to localStorage so the page remembers them next visit — never the pattern or the test text. You can verify by opening DevTools → Network: typing in either box fires zero requests. This makes the tool safe for proprietary patterns, redacted log samples, internal config, and anything else you would not paste into regex101. **Q: What regex flavor does this tester use — PCRE, Python, Java, JavaScript?** A: ECMA-262 (JavaScript), the dialect implemented by V8, JavaScriptCore, and SpiderMonkey — the same engine you get from `new RegExp(pattern, flags)` in any browser, Node.js, Deno, or Bun. That means the supported features are: capture groups (numbered + named with `(? ...)`), lookaheads `(?=...)` and `(?!...)`, lookbehinds `(?<=...)` and `(?...)`, possessive quantifiers `a++`, conditionals `(?(1)yes|no)`, and inline modifiers `(?i)` will throw a syntax error. Python's `re.VERBOSE` is not supported here. For Python/Java/Go regex, port the pattern back to its native engine — most simple patterns transfer unchanged, and the explainer here is flavor-neutral. **Q: What do each of the flags g, i, m, s, u, y, d do?** A: g (global) — find every match, not just the first; required for iterating with .matchAll and for global replace. i (case-insensitive) — A and a match the same character. m (multiline) — ^ and $ anchor at every line break, not just the start/end of the whole input. s (dotAll) — . matches newlines too; without /s a dot stops at \n. u (unicode) — enables \u{HHHH} escapes, Unicode property escapes (\p{Letter}), and treats the pattern as a sequence of Unicode code points instead of UTF-16 code units. y (sticky) — anchors each match at lastIndex, useful for tokenisers. d (hasIndices, ES2022) — populates `.indices` and `.indices.groups` with [start, end] pairs for every capture; this tester uses /d under the hood to draw the group boundaries. Toggle them as chips above the test text; the canonical /pattern/flags literal is shown in the readout. **Q: How do I write capture groups and how do I refer back to them?** A: Wrap a sub-pattern in parentheses: `(\d{4})-(\d{2})-(\d{2})` gives you three positional groups, accessible as $1, $2, $3 in replacements or as m.groups[0..2] in the Matches panel. Use `(? ...)` for named groups: `(? \d{4})-(? \d{2})` lets you write $ /$ in the replacement template. Use `(?:...)` for a non-capturing group when you only need grouping for a quantifier (`(?:foo|bar)+`) — it does not create a back-reference, which keeps your numbered $1..$N stable. Inside the same pattern, refer to an earlier capture with `\1`, `\2`, etc. — handy for finding doubled words like `\b(\w+)\s+\1\b`. **Q: How do lookahead and lookbehind work, and what are they good for?** A: Lookarounds are zero-width assertions — they check that something matches (or doesn't) without consuming characters. `(?=foo)` (positive lookahead) succeeds if `foo` follows the current position; `(?!foo)` (negative lookahead) succeeds if `foo` does NOT follow. `(?<=foo)` and `(?2KB samples copy the regex via Copy /pattern/flags and paste the text separately. For collaborative regex review without sharing the actual text, share just the pattern and flags — the recipient pastes their own corpus and gets the same matches. **Q: Does the tester support Unicode, emoji, and non-Latin scripts?** A: Yes. Enable the /u flag to opt into full Unicode handling: \w matches Latin word characters (the default semantic), but with /u you can match wider categories via Unicode property escapes — `\p{Letter}` matches every letter in every script, `\p{Script=Han}` matches Chinese ideographs, `\p{Emoji}` matches emoji, `\p{Number}` matches every digit/numeral. Without /u, surrogate-pair emoji like 👨💻 are seen as two UTF-16 code units and patterns like `^.$` will fail to match them; with /u the dot treats each grapheme code point as one character. For RTL scripts (Arabic, Hebrew), patterns work without special handling — direction is a render-time concern, not a regex-engine concern. CJK content matches the same way as Latin. **Q: What's the difference between .match, .matchAll, .replace, and .split with a regex?** A: String.prototype.match returns the first match (or an array of all matches when /g is set) but loses capture groups when /g is on. String.prototype.matchAll requires /g and returns an iterator of match arrays WITH capture groups and indices — what this tester uses internally. String.prototype.replace accepts either a string template ($1, $&, etc) or a callback called per match with (match, ...groups, offset, string, namedGroups). String.prototype.split splits on every match — useful with /g but the global flag is ignored for split semantics. This tool exposes match via the Match tab, replace via Replace, and split via Split, so you can preview every flavour without leaving the page; the literal /pattern/flags is one click away when you're ready to paste into code. **Q: Why doesn't my Python or Java regex work here?** A: Because this tester runs ECMA-262 (JavaScript) — most patterns port cleanly, a handful don't. Common porting gotchas: (1) Python's inline flags `(?i)` and `(?x)` are not valid in JS — use the flag chips above instead. (2) Python's `\A` and `\Z` are `^` and `$` in JS (with /m for line anchors). (3) Java/Python conditionals `(?(name)yes|no)` are not supported in JS — rewrite with an alternation. (4) Possessive quantifiers `a++` and atomic groups `(?>...)` are JS-unavailable — simulate with `(?=(a+))\1`. (5) Python `(?P ...)` is `(? ...)` in JS. (6) `\h` for horizontal whitespace and `\v` for vertical are not in JS — use `[ \t]` and `[\n\r]`. For a portable port, the explainer breaks down what each token does so you can swap the unsupported syntax for an equivalent. **Q: Is there a maximum text size or match count?** A: Practical limit: about 200,000 characters of test text and 500 highlighted matches displayed at once. Beyond 500 matches the Matches panel shows a Showing first 500 banner; the count badge still reports the true total. The 250ms wall-clock budget bounds runaway patterns regardless of size. For multi-megabyte log files, run the regex with command-line `grep -oE` or `rg` (ripgrep) — they stream and won't hit a UI rendering cap. For one-off scans of huge text, paste a representative slice into this tester to validate the pattern, then run the validated pattern against the full file in your shell. --- ### REM to PX Converter — Convert Rem to Pixels URL: https://go-tools.org/tools/rem-to-px Convert rem to px instantly. 1rem = 16px at the default base, plus any custom root font-size. Free, live two-way conversion that runs 100% in your browser. #### What Is a REM to PX Converter? A rem to px converter translates rem units into pixel measurements. The rem ("root em") unit is relative to the font-size of the root element: 1rem always equals the root font-size, which browsers set to 16px by default. The conversion is a simple multiplication — px = rem × root-font-size — but checking it for every value while reading or debugging a stylesheet is repetitive, which is what this tool removes. Developers usually author CSS in rem for accessibility and scalability: values written in rem scale with the user's browser font-size preference, while px values stay fixed. But there are many moments when you need the pixel figure — matching a design mockup, handing off sizes to a designer who works in pixels, setting a px-only property, or debugging why an element renders at a particular size. That is when converting rem back to px is exactly what you want. This converter keeps the rem and pixel fields linked in real time, so you can move in either direction, and — unlike tools that hard-code a 16px base — it lets you set any root font-size. That matters because a stylesheet using the 62.5% technique (a 10px root) resolves rem to different pixel values than a default 16px setup. A live preview shows the resulting text size, and a reference table lists common rem values at a 16px base for quick lookups. Need the other direction? Use the px to rem converter. For cleaning up the stylesheet itself, try the CSS formatter, and for color work see the color converter. Everything runs in your browser — your values never leave your device. ``` /* The core formula */ /* px = rem × root-font-size (16px by default) */ :root { font-size: 16px; /* 1rem = 16px */ } /* 1.5rem -> 24px */ /* 1rem -> 16px */ /* 0.75rem -> 12px */ /* 2rem -> 32px */ /* JavaScript equivalent */ const remToPx = (rem, base = 16) => rem * base; console.log(remToPx(1.5)); // 24 console.log(remToPx(0.75)); // 12 ``` #### FAQ **Q: What is 1rem in pixels?** A: 1rem equals the root font-size in pixels — 16px by default. The rem unit is relative to the font-size of the root element, so px = rem × root-font-size. On a standard setup 1rem = 16px, 1.5rem = 24px, and 2rem = 32px. If a stylesheet changes the root font-size, the pixel value of 1rem changes with it. **Q: How do you convert rem to px?** A: To convert rem to px, multiply the rem value by the root font-size (16px by default). The formula is px = rem × base. For example, 1.5rem × 16 = 24px, and 0.75rem × 16 = 12px. This tool does the multiplication for you in real time and lets you change the base if your project uses a different root font-size. **Q: What is 16px in rem?** A: 16px equals 1rem at the default 16px root font-size, because rem = px ÷ base. This is the reverse of the rem-to-px direction: 1rem = 16px, so 16px = 1rem. Change the base in the tool, or use the px to rem converter, if your project does not use a 16px root. **Q: Why do designs use rem instead of px?** A: Rem units respect the user's browser font-size preference, which is important for accessibility. When someone increases their default font size, everything sized in rem scales proportionally, while px values stay fixed. Rem also keeps a design system consistent — change one root font-size and the whole interface rescales. Converting rem back to px is still useful for pixel-precise review, design hand-off, and debugging. **Q: What is the difference between rem, em, and px?** A: px is an absolute unit — a fixed CSS pixel. rem is relative to the root () font-size, so it is consistent across the page. em is relative to the font-size of the current element's parent, so it compounds when nested. Use rem for most sizing so it scales with the user's preference, px for fixed details like 1px borders, and em when you want a value to scale relative to its local context. **Q: What is the 62.5% font-size trick?** A: Setting html { font-size: 62.5% } makes the root font-size 10px (62.5% of the 16px default). With a 10px base, 1rem = 10px, so rem-to-px is just "multiply by 10": 1.6rem = 16px, 2.4rem = 24px. Many developers like the simpler arithmetic, then set body { font-size: 1.6rem } for readable 16px body text. Set this tool's root font-size to 10 to convert against the 62.5% base. **Q: Can I change the root font-size in this converter?** A: Yes. The Root font-size field defaults to 16px but accepts any value — 10, 18, 20, or whatever your project uses. Every conversion and the reference table update against the base you set. Click 'Reset to 16' to return to the default. Most converters hard-code 16px; the custom base is what lets this tool match your real stylesheet. **Q: Is 1rem always 16px?** A: Only when the root font-size is 16px, which is the default in virtually all browsers. The relationship 1rem = 16px holds as long as html { font-size } is not overridden. If a stylesheet sets the root font-size to 10px or 18px, then 1rem equals that value instead. Always convert against the page's actual root font-size. **Q: When should I convert rem back to px?** A: Converting rem to px is useful when you need pixel-precise values: matching a design mockup, communicating sizes to a designer who works in pixels, setting a px-only property, or debugging why an element renders at a certain size. The rem authoring stays in your CSS for scalability; the px figure is for verification and hand-off. **Q: Does it matter which root font-size I use for the conversion?** A: Yes — the root font-size is the multiplier, so it directly changes the result. 2rem is 32px at a 16px base but 20px at a 10px base. If your stylesheet uses the 62.5% technique or any custom root font-size, set the tool's base to match, or the pixel values will be wrong. **Q: How accurate is this rem to px converter?** A: Conversions use IEEE 754 double-precision arithmetic and the exact formula px = rem × base, with results rounded to at most five decimal places and trailing zeros trimmed. That is far finer than the browser needs, and the math is deterministic, so you can rely on it for production work. **Q: Is my data safe when using this converter?** A: Completely. All conversions run locally in your browser using JavaScript. No values are sent to any server — there are no network requests, no cookies on your input, and no analytics on what you type. You can verify it by disconnecting from the internet: the tool keeps working fully offline once the page has loaded. --- ### Remove Duplicate Lines from Text URL: https://go-tools.org/tools/remove-duplicate-lines Remove duplicate lines from text online — free, instant, 100% in your browser. Ignore case or whitespace, keep first or last occurrence, and see how many duplicates were removed. Also sort and clean up. No signup. #### What Does Removing Duplicate Lines Mean? Removing duplicate lines — deduplication, or "dedupe" — means scanning a block of newline-separated text and keeping only one copy of each distinct line. It is one of the most common cleanup tasks anyone who works with data runs into: collapsing a mailing list that accumulated repeats, reducing a log to its unique messages, finding the distinct values in a spreadsheet column, or merging several lists into one clean set. The interesting question is what counts as a duplicate. Byte-for-byte comparison is the strict answer, but real data is messier. Two lines can look identical yet differ by a trailing space, or vary only in capitalization — `Error` versus `error`. This tool lets you decide: by default it ignores case, and you can enable whitespace-insensitive comparison so lines are matched on their trimmed, lowercased form. That way you deduplicate on the meaning of a line rather than its exact encoding, which is almost always what you actually want. The other decision is which copy to keep. Keeping the first occurrence preserves the original order and is the default; keeping the last is useful when later entries supersede earlier ones. Either way, the result is deterministic and the live stats badge tells you exactly how many duplicates were removed, so you never have to trust the tool blindly. Deduplication pairs naturally with sorting and other cleanup. This tool folds them into one panel: remove duplicates, then optionally sort, trim whitespace, drop blank lines, reverse, or add line numbers. When sorting is the main event, use the companion Sort Text Lines tool, which shares the same engine. To count the lines and words in your text, use the Word Counter; to see what changed between two versions of a list, use Text Diff; and to normalize casing before deduplicating, use the Case Converter. Everything runs entirely in your browser with no uploads, so deduplicating a confidential list is exactly as private as editing it locally. Paste, and the unique result is ready to copy in a second. ``` Input: alice@example.com bob@example.com alice@example.com ALICE@example.com Exact dedupe (case-sensitive): alice@example.com bob@example.com ALICE@example.com Case-insensitive dedupe (default): alice@example.com bob@example.com ← ALICE collapsed into alice ``` #### FAQ **Q: What does this tool do?** A: It removes duplicate lines from a block of text, keeping each unique line once. As you paste or type, the deduplicated result appears instantly with a live count of lines in, lines out, and how many duplicates were removed. You can control what counts as a duplicate (ignore case, ignore whitespace), choose to keep the first or last occurrence, and optionally sort, trim, remove empty lines, or add line numbers in the same pass. Everything runs 100% client-side in your browser — nothing is uploaded, logged, or stored — so it is safe for emails, logs, and any confidential list. You can confirm this in your browser's Network tab: deduplicating triggers zero network requests. **Q: Does it keep the first or last occurrence of a duplicate?** A: By default it keeps the first occurrence and removes later repeats, which preserves the original order of your list. Switch Keep occurrence to Last to keep the final appearance of each line instead — the surviving line then sits at its last position. Keep-first is the right choice most of the time (it is what `sort -u` and most dedupe tools do); keep-last is handy when later entries supersede earlier ones, such as configuration overrides, environment variables, or a log where the newest status wins. The stats badge reports the same duplicate count either way. **Q: Is my text uploaded anywhere?** A: No. Deduplication and every other operation run entirely in your browser using JavaScript. Your text is never transmitted, never stored on any server, never logged, and never analyzed. This makes the tool safe for email lists, access logs, internal data, and any content you would not paste into a networked service. No cookies capture your input and no third-party analytics read what you type. Open your browser's developer tools and watch the Network tab while you paste a huge list — you will see zero requests, because the work happens locally. **Q: How do I remove duplicates but ignore case?** A: Leave Case-sensitive off — that is the default. With it off, `Error`, `error`, and `ERROR` are treated as the same line and collapsed to a single entry (the first one encountered, in its original casing). Turn Case-sensitive on only when the casing is meaningful and `ID` should be kept separate from `id`. Case handling applies to the comparison, not the output: the surviving line keeps whatever casing it originally had; only the decision about which lines are duplicates changes. **Q: Why aren't my visually identical lines being deduplicated?** A: Almost always the culprit is invisible whitespace — a trailing space, a tab, or a non-breaking space — that makes two lines differ byte-for-byte even though they look the same. Turn on Ignore leading/trailing spaces so lines are compared after trimming, and the duplicates will collapse. This is extremely common in data pasted from spreadsheets, PDFs, and terminal output. If lines still won't merge, they may differ by an internal character (a double space vs single space, or a smart quote vs a straight quote); trim only handles the edges. **Q: Does removing duplicates change the order of my lines?** A: No — with keep-first (the default), the surviving lines stay in their original order; only the repeated appearances are removed. So deduplicating `a, b, a, c` gives `a, b, c` in that order. If you also want the result sorted, enable a sort order and the tool will deduplicate first, then sort. With keep-last, order is still based on original positions, but each surviving line moves to where its last occurrence was. In every mode the output is deterministic, so the same input and settings always produce the same result. **Q: Can I remove duplicates and sort at the same time?** A: Yes. Enable a sort order (Ascending or Descending) while deduplication is on, and you get a clean, unique, ordered list in a single step. The pipeline removes duplicates first, then sorts, so nothing is lost. If sorting is your primary goal and dedupe is secondary, the companion Sort Text Lines tool shares the same engine and opens with sorting enabled. Both tools expose the full option set; they differ only in which task they lead with. **Q: What happens to blank lines?** A: By default, blank lines are treated like any other line: if the same blank line appears twice, the duplicate is removed, but a single blank line is preserved. If you want to drop all blank and whitespace-only lines entirely, enable Remove empty lines — the stats badge counts them separately from duplicates, so you can see `6 lines → 3 lines · 1 duplicates removed · 2 empty removed`. A single trailing newline at the end of your input is treated as a line terminator, not an extra blank line, so it won't skew the counts. **Q: Is there a limit on list size?** A: There is no hard limit built into the tool; it is bounded only by your browser's memory and how much text you can paste into a textarea. Deduplication uses a hash set, so it is fast even for large lists — tens of thousands of lines are instantaneous and hundreds of thousands complete with a brief pause. Because everything runs locally, large lists are often quicker here than on server-based tools that must upload your data first. For multi-million-line files, a command-line tool like `sort -u` or `awk '!seen[$0]++'` will be more comfortable, but for everyday lists this handles them easily. **Q: How does this compare to the command line (sort -u, awk, uniq)?** A: `sort -u` removes duplicates but also sorts, and `uniq` only collapses adjacent duplicates (so it requires pre-sorted input). `awk '!seen[$0]++'` removes duplicates while preserving original order — the same as this tool's keep-first mode — but requires a terminal. This tool gives you order-preserving dedupe, keep-first or keep-last, case- and whitespace-insensitive comparison, optional sorting, and a live count, all without leaving the browser or installing anything. It is the fastest option when the list is already on your clipboard rather than in a file. **Q: How is this faster than removing duplicate lines in Excel or Notepad++?** A: In Excel you'd use Data → Remove Duplicates on a column, and Notepad++ needs a TextFX or sort-then-uniq plugin — both require the data to already be inside that app. This tool works the moment text is on your clipboard: paste it and duplicate lines are removed instantly, with case- and whitespace-insensitive matching, keep-first or keep-last, and a live duplicate count those tools don't show. It also preserves the original order, unlike Excel's row-based removal or a sort-first approach, and nothing is uploaded. When you just need to dedupe a chunk of text quickly, it beats switching to a spreadsheet or installing a plugin. **Q: Can I use this to find unique values in a column?** A: Yes. Copy a single column out of a spreadsheet or CSV, paste it here, and the deduplicated output is the set of unique values. Enable Ignore leading/trailing spaces to catch values that differ only by stray whitespace, and turn on a sort order if you want them alphabetized. The stats badge tells you how many duplicates existed, which doubles as a quick way to gauge the cardinality of the column. Paste the unique result back into your sheet or query when you're done. --- ### RGB to Hex Converter URL: https://go-tools.org/tools/rgb-to-hex Convert RGB to hex in your browser — integers, percentages, and rgba alpha all supported. Free, instant, no signup, your colors never leave the page. #### What Is an RGB to Hex Converter? An RGB to hex converter is a small utility that turns three 0-255 integer channel values (`rgb(255 87 51)`) into the 6-character hex code that encodes the same color (`#FF5733`). RGB and hex are the two formats every web stylesheet, design tool, and image-pixel pipeline has been built around since the late 1990s, and the conversion between them is the single most common operation in color tooling — paired with its inverse direction, this exact transform runs millions of times per day across every Figma plugin, CSS preprocessor, design-token build, and color-picker UI on the web. RGB is the channel-addressed format that hardware APIs, canvas drawing calls, image-buffer manipulation, OpenGL color attributes, and most graphics SDKs report natively — three separate 0-255 integers that map directly to the red, green, and blue subpixels of an LCD or the phosphors of a CRT. Hex is the terse copy-paste format that Figma, Sketch, Photoshop, and every brand-guidelines PDF expect for output — a 6-character base-16 string that fits in a CSS custom property comfortably and reads at a glance once your eyes learn the patterns. Converting between them is mechanical: convert each integer to a 2-digit base-16 pair and concatenate with a leading `#`. This tool runs that conversion live as you type, with no "Convert" button to click, and surfaces every other common color format (HSL, OKLCH, OKLAB, HSV, HWB, CMYK, plus the 148 CSS named colors) alongside the HEX output for free. **The hex format itself deserves a closer look.** Standard CSS hex comes in four legal shapes. The canonical 6-digit form `#RRGGBB` packs three 8-bit channels into 6 base-16 digits — 16,777,216 colors total (256³). The 3-digit shorthand `#RGB` is a compressed form where each digit is duplicated to form the 6-digit equivalent: `#F73` expands to `#FF7733`, *not* `#000F73` (this is one of the most-mistaken rules in CSS color syntax). The 8-digit alpha form `#RRGGBBAA` appends a 2-digit alpha pair on a 0-`FF` scale, with `00` fully transparent and `FF` fully opaque. The 4-digit alpha shorthand `#RGBA` mirrors 3-digit shorthand by duplicating each digit, including the alpha digit. Hex is case-insensitive — `#ff5733` and `#FF5733` parse identically, though most brand guidelines pick a case convention and stick with it. The base-16 choice is convenient because one hex digit = nibble = 4 bits, two digits = byte = 0-255, so a single 2-digit pair maps cleanly to one 8-bit channel with no padding waste. The conversion math goes both directions cleanly. **RGB to HEX**: for each channel, call `value.toString(16).padStart(2, '0')` to get the 2-digit hex pair (the `padStart` matters — without it, channel value 5 would serialize as `'5'` instead of `'05'`, producing invalid hex), then concatenate. For alpha-bearing RGB (`rgb(R G B / A)` or `rgba(R, G, B, A)`), multiply the 0-1 alpha float by 255, round to the nearest integer, hex-encode as a 4th pair, and emit the 8-digit form. **HEX to RGB** is the inverse: parse the 6-digit hex `#RRGGBB` as three 2-digit base-16 numbers via `parseInt(hex.slice(1, 3), 16)`, etc. Both directions are bit-exact: 16² = 256, exactly matching the 0-255 byte range each channel occupies, so an RGB → HEX → RGB round-trip produces the original integers verbatim with no float drift. **Why HEX over RGB in CSS?** Three reasons. Hex is shorter — `#FF5733` is 7 characters versus `rgb(255, 87, 51)` at 16 characters, a meaningful difference when packed into a CSS custom property or a Tailwind config object. Hex has no whitespace bugs — CSS minifiers, JSON serializers, and command-line tools all handle a 7-character string cleanly without worrying about parenthesis matching or comma escaping. And hex is the format the entire design-tool ecosystem speaks natively — Figma's color panel, Sketch's swatches, Photoshop's color picker, every brand-guidelines PDF, every Dribbble shot's color callout — they all export hex by default. The copy-paste path from designer to developer is hex-shaped, which is why the RGB-to-HEX conversion is so frequent: developers receive RGB from a non-design tool (a canvas call, a screenshot eyedropper, a hardware sensor) and need to turn it into the hex form that the rest of their stack expects. This tool's RGB → HEX workflow is one direction of a 5-spoke family that all share the same underlying unified color converter. The dedicated unified color converter is the hub — it shows all 9 formats simultaneously editable and is the right tool when your workflow needs more than just RGB and hex. The single-direction spokes target specific Google search intents: the reverse hex to RGB converter for the inverse direction (taking a hex from Figma and pulling out the 0-255 integers), the hex to HSL converter for the legacy designer-cognitive space, the hex to OKLCH converter for modern perceptually-uniform design systems (Tailwind v4 and shadcn both default to OKLCH now), and the hex to CMYK converter for print-prep approximations. All five spokes and the hub share the same parsing engine and the same conversion math, so the results are guaranteed identical across the family. Every conversion runs locally in your browser — your RGB values are never uploaded, never logged, and zero network requests fire as you type. Verify in DevTools. ``` // Serialize {r, g, b, alpha} → canonical hex string // Emits 6-digit #RRGGBB when alpha === 1, 8-digit #RRGGBBAA otherwise. function formatHex({ r, g, b, alpha = 1 }) { const pair = (v) => Math.round(v).toString(16).padStart(2, '0').toUpperCase(); const rgb = pair(r) + pair(g) + pair(b); if (alpha >= 1) return `#${rgb}`; const a = pair(alpha * 255); return `#${rgb}${a}`; } console.log(formatHex({ r: 255, g: 87, b: 51 })); // '#FF5733' console.log(formatHex({ r: 59, g: 130, b: 246 })); // '#3B82F6' console.log(formatHex({ r: 255, g: 87, b: 51, alpha: 0.5 })); // '#FF573380' console.log(formatHex({ r: 5, g: 0, b: 0 })); // '#050000' — padStart matters ``` #### FAQ **Q: How do you convert RGB to hex?** A: Convert each 0-255 channel integer to a 2-digit base-16 string, then concatenate with a leading `#`. In JavaScript: `[255, 87, 51].map(v => v.toString(16).padStart(2, '0')).join('')` returns `'ff5733'`. The `padStart(2, '0')` matters — without it, single-digit values like `5` serialize as `'5'` instead of `'05'`, producing an invalid hex. This tool runs the conversion live as you type — paste any `rgb()` value (with or without spaces, with comma or modern space syntax, with or without alpha) and the HEX field updates instantly with the matching `#RRGGBB` or 8-digit `#RRGGBBAA` value. **Q: What is RGB in hex?** A: RGB in hex is the same color encoded as a 6-character base-16 string. Both forms describe a color as three channels (red, green, blue) on the 0-255 scale, anchored to the sRGB color space. `rgb(255 87 51)` and `#FF5733` are interchangeable anywhere a ` ` is accepted in CSS — they round-trip losslessly. Hex packs the same information into a terser form that fits cleanly in CSS variables and copies cleanly between Figma, Sketch, Photoshop, and code; `rgb()` keeps the channels addressable as separate integers for canvas calls and hardware APIs. **Q: How do I get the hex code from RGB?** A: Take each channel value (0-255), call `toString(16)` to get its base-16 representation, left-pad with zero to 2 digits, and concatenate with a leading `#`. `rgb(255 87 51)` becomes: `255 → 'ff'`, `87 → '57'`, `51 → '33'`, result `#ff5733`. Capitalize if your style guide requires it (`#FF5733`); both forms are valid CSS. For alpha-bearing RGB like `rgb(255 87 51 / 0.5)`, multiply the alpha by 255, round, and append the resulting 2-digit hex pair: `0.5 × 255 = 128 = 0x80`, result `#ff573380`. This tool does both transforms automatically. **Q: What is the formula for RGB to hex?** A: For each channel: `value.toString(16).padStart(2, '0')`. The `toString(16)` converts the integer to its base-16 representation; the `padStart(2, '0')` ensures the result is exactly 2 characters (necessary for values under 16, which would otherwise serialize as 1 character). Concatenate the three results, prepend `#`, and you have the canonical hex. Mathematically: for channel `n` in `[0, 255]`, the hex digits are `Math.floor(n / 16)` and `n % 16` mapped through `'0123456789abcdef'`. There is no rounding loss — 16² = 256, exactly matching the 0-255 byte range each channel occupies. **Q: Does rgb(0,0,0) equal #000000?** A: Yes — exactly. `rgb(0, 0, 0)` and `rgb(0 0 0)` (modern space-separated CSS Color 4 syntax) both serialize to `#000000`, pure black with all three channels at zero. Every channel pair encodes as `00`, concatenated to a 6-character hex `000000`. The same equivalence holds at the other extreme: `rgb(255, 255, 255)` ↔ `#FFFFFF` (pure white). Any RGB triple has exactly one canonical 6-digit hex representation, and any 6-digit hex has exactly one RGB triple — the mapping is bijective across the full 16,777,216-color sRGB space. **Q: Can RGB have an alpha channel?** A: Yes — use the `rgba()` legacy form `rgba(255, 87, 51, 0.5)` or the modern CSS Color 4 slash syntax `rgb(255 87 51 / 0.5)`. Both encode an alpha float from 0 (fully transparent) to 1 (fully opaque). When converting to hex, alpha becomes a 4th 2-digit pair appended after RGB: multiply by 255, round, hex-encode. `0.5 × 255 = 128 = 0x80`, so `rgb(255 87 51 / 0.5)` becomes `#FF573380`. 8-digit hex with alpha shipped in all evergreen browsers in 2018; before that, the `rgba()` form was the only way to express alpha in CSS. **Q: How do hex and RGB differ?** A: They encode the same color in different notation. Hex packs three 0-255 channels into a 6-character base-16 string (`#FF5733`); `rgb()` spells the channels out in decimal (`rgb(255 87 51)`). Hex is shorter and design-tool-native — Figma, Sketch, Photoshop, and every brand guidelines PDF export hex by default, and most front-end developers can recognize `#3b82f6` as Tailwind blue-500 on sight. RGB is explicit channel-addressing, easier to compute against in JavaScript, and the only form that accepts percentage channels and natively-syntaxed alpha. Both are equally valid CSS and round-trip losslessly. **Q: How accurate is RGB to hex?** A: Bit-exact. RGB → hex is integer-to-string math with zero float involvement: `toString(16).padStart(2, '0')` produces the canonical 2-digit hex pair for every value in 0-255, and the reverse (`parseInt(pair, 16)`) recovers the original integer exactly. A round-trip RGB → HEX → RGB → HEX produces the original tuple verbatim, indefinitely. 16² = 256, exactly matching the byte range, so there's no rounding loss in either direction. Percentage RGB inputs round to the nearest integer first (`50% × 255 / 100 = 127.5 → 128`), which is the standard CSS Color 4 normalization rule. --- ### Free Online RSA Key Pair Generator — ECDSA and Ed25519 URL: https://go-tools.org/tools/rsa-key-generator Generate an RSA key pair online — the private key never leaves your browser. RSA 2048/4096, ECDSA and Ed25519, in PKCS#8 or PKCS#1 PEM, with JWK and fingerprint. #### What is an RSA key generator? An RSA key generator produces a mathematically linked pair: a private key you keep and a public key you hand out. Anything signed with the private half can be verified with the public half, and only the public half is safe to publish. That asymmetry is the whole point — it is what lets a verifier check your signatures without gaining the ability to forge them, which a shared secret can never offer. This generator runs inside your browser through the Web Crypto API, so the private key is created in the tab and the page makes no network request while generating. Beyond RSA it also produces ECDSA and Ed25519 pairs, which serve the same purpose with much shorter keys: an Ed25519 private key is 48 bytes in PKCS#8 where a 2048-bit RSA key runs past 1.2 KB. The part that trips people up is not the mathematics but the packaging. The same key can be written as PKCS#8, PKCS#1, SPKI or JWK, and a library that rejects one will often accept another with no clearer message than a parse error. The table further down maps each container to the ecosystems that expect it. ``` // Verify a downloaded key pair matches, using OpenSSL: openssl pkey -in rsa-2048-private.pem -pubout | diff - rsa-2048-public.pem // No output means the public key really belongs to that private key. ``` #### FAQ **Q: Is it safe to generate a private key on a website?** A: The key is generated by the Web Crypto API in your own browser, and this page makes no network request while generating — you can watch the Network panel, or disconnect and see that generation still works. Be clear about what that shows and what it does not: it demonstrates the page needs no server, but it is not proof against a compromised script, since the JavaScript is re-fetched from our server on every visit. The risks that remain are the browser's rather than the network's — a malicious extension can read the page and your clipboard, and anyone with access to the machine can read the downloaded file. For a key protecting production systems, generate it on the host that will use it; the OpenSSL commands below do exactly that. This page is the right tool for development, testing, learning, and anywhere a browser-generated key is acceptable. **Q: What is the difference between PKCS#8 and PKCS#1?** A: They are two containers for the same RSA key. PKCS#1, marked BEGIN RSA PRIVATE KEY, holds the RSA numbers directly and exists only for RSA. PKCS#8, marked BEGIN PRIVATE KEY, wraps those same numbers in an algorithm identifier, which lets one format carry RSA, ECDSA and Ed25519 alike. Most modern libraries expect PKCS#8 — the JDK, notably, reads only PKCS#8 without an extra library — while a number of payment gateways and older OpenSSL-era tooling still require PKCS#1. Switching the toggle on this page re-encodes the key already on screen, so no information is added or lost and the fingerprint stays the same. **Q: How do I convert a PKCS#1 key to PKCS#8, or back?** A: Switch the PEM structure toggle on this page and the same key is re-emitted in the other container. For a file you already have, OpenSSL converts locally: openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem turns a BEGIN RSA PRIVATE KEY file into BEGIN PRIVATE KEY, and openssl rsa -traditional -in pkcs8.pem -out pkcs1.pem goes the other way. Neither direction adds or removes key material; only the wrapper changes, which is why both files describe the identical key and produce the identical fingerprint. **Q: How do I get the public key from an RSA private key?** A: The public key is derivable from the private key, never the reverse. This page shows both halves at once, so there is nothing to derive. For a private key you already have on disk, openssl pkey -in private.pem -pubout -out public.pem writes the matching BEGIN PUBLIC KEY file. That is also how you check whether a pair belongs together — regenerate the public half and compare it against the file you were given. **Q: Should I choose RSA or Ed25519?** A: Choose Ed25519 when nothing forces your hand. It reaches security comparable to RSA 3072 with a 32-byte key, signs faster, and has no parameters to misconfigure. Choose RSA when a counterparty, a certificate authority or an old library requires it, which is still common in enterprise and payment systems. ECDSA sits between the two and is widely supported in TLS. **Q: Is 2048-bit RSA still strong enough?** A: Yes, for most purposes today. NIST rates 2048-bit RSA at 112-bit security strength and carries it through 2030 in SP 800-57; 3072-bit reaches 128-bit strength and is what NIST points to beyond that. So: 2048 for anything you will rotate within a few years, 3072 or 4096 for a key you expect still in service in the 2030s or where a certificate authority requires it. The cost of the larger key is slower signing and larger signatures, not weaker security. **Q: Can I use these keys to sign JWTs?** A: Yes. RSA keys work with RS256, RS384 and RS512 as well as the PSS variants; ECDSA P-256 pairs with ES256; and Ed25519 is the EdDSA algorithm. Sign with the private key and publish the public key so verifiers can check signatures without being able to create them. One caveat if you use the JWK panel rather than the PEM: Web Crypto stamps an RSA JWK with alg RS256, and strict libraries refuse to load it for PS256 or RS512 — delete the alg member, or use the PEM. Our JWT encoder accepts these keys, and the decoder shows what the resulting token contains. **Q: Can this generate an SSH key?** A: Not directly. OpenSSH's own private key file is a different container, and this page does not write it. An RSA key from here is still usable: ssh-keygen -y -f rsa-2048-private.pem > id_rsa.pub derives the authorized_keys line from the file you downloaded. Ed25519 keys from here are not, because OpenSSH rejects the PKCS#8 form. For SSH access the better answer remains ssh-keygen -t ed25519 on the machine that needs the key, which avoids moving a private key at all. For JWT signing, CI release signing and webhook verification, the PKCS#8 key this page produces is exactly what those tools want. **Q: Can I protect the private key with a passphrase?** A: Not here. Encrypted PKCS#8 requires a key derivation step that the Web Crypto API does not expose, so implementing it would mean hand-rolling cryptography in JavaScript. Add the passphrase locally instead: openssl pkcs8 -topk8 -in private.pem -out encrypted.pem reads the file you downloaded and prompts for one. **Q: What is the fingerprint for?** A: It is a SHA-256 digest of the public key structure, short enough to compare by voice or in a chat message. When you send someone a public key, comparing fingerprints over a separate channel confirms that what arrived is what you sent. It identifies the public key only and reveals nothing about the private half. Note that it is not the number ssh-keygen -l prints: OpenSSH hashes its own wire format rather than the SPKI structure, so the two never match for the same key. --- ### SHA-1 Hash Generator (160-bit Legacy) URL: https://go-tools.org/tools/sha-1-generator Generate SHA-1 hashes in your browser — 40-character hex output, no upload. Legacy tool for Git fingerprints, old certificate checks, and migration audits. Data never leaves your device. #### What Is SHA-1? SHA-1 (Secure Hash Algorithm 1) is a 160-bit cryptographic hash function published by NIST in 1995 as FIPS 180-1. It was designed by the U.S. National Security Agency to replace SHA-0 (a flawed earlier version quickly withdrawn in 1993) and was the dominant hash algorithm for digital signatures, TLS certificates, and code signing through the 2000s. History of breaks: In 2005, Xiaoyun Wang's team published a theoretical attack reducing SHA-1 collision resistance from the expected 2^80 to 2^63 operations — a theoretical break, but not yet practical. In February 2017, Google and CWI Amsterdam released the SHAttered attack, producing two distinct PDF documents with identical SHA-1 hashes using approximately 110 GPU-years of computation. This was the definitive practical break. NIST had already deprecated SHA-1 for signatures in 2011 (NIST SP 800-131A); browser vendors and Certificate Authorities followed by removing SHA-1 certificate support in 2016–2017. Current status: SHA-1 is deprecated for all security-sensitive uses — digital signatures, certificate fingerprints, password storage, and code signing. It persists in Git's object-ID format (commit hashes), where it is used for content addressing rather than security, and in legacy software checksums where administrators have not yet migrated. The Git project added SHA-256 object format support in version 2.29 (October 2020). All new projects should use SHA-256 or stronger. This tool computes SHA-1 entirely in your browser using crypto.subtle.digest('SHA-1', ...)from the Web Crypto API. The 40-character hex output is identical to whatsha1sum,openssl dgst -sha1, orgit hash-objectproduce. No bytes are sent to any server. SHA-1 vs the SHA-2 family: SHA-1 produces 40 hex chars (160 bits). SHA-256 produces 64 hex chars (256 bits) and has no known weaknesses. MD5 produces 32 hex chars (128 bits) and was broken earlier (2004). For any new hashing work, SHA-256 is the standard choice. ``` // Hash text using Web Crypto API (SHA-1 — legacy use only) async function sha1(text) { const data = new TextEncoder().encode(text); const hash = await crypto.subtle.digest('SHA-1', data); return Array.from(new Uint8Array(hash)) .map(b => b.toString(16).padStart(2, '0')) .join(''); } await sha1('Hello, World!'); // → '0a0a9f2a6772942557ab5355d76af442f8f65e01' // ⚠️ SHA-1 is broken — use SHA-256 for new work. ``` #### FAQ **Q: Is SHA-1 still safe to use?** A: No. SHA-1 was theoretically weakened in 2005, and in February 2017 Google and CWI Amsterdam demonstrated the first practical collision via the SHAttered attack — two different PDF files with identical SHA-1 hashes. NIST deprecated SHA-1 for digital signatures in 2011 (NIST SP 800-131A) and all major browsers and Certificate Authorities stopped accepting SHA-1 certificates by 2017. SHA-1 is broken for any security-sensitive use: signatures, certificates, password storage. For all new work, switch to SHA-256. **Q: Why does Git still use SHA-1?** A: Git uses SHA-1 for object IDs (commit hashes, tree hashes, blob hashes) because it was designed in 2005 when SHA-1 was still widely trusted. Git's use is not a cryptographic signature — it is a content-addressing scheme used to detect accidental corruption, not deliberate tampering. The Git project has been migrating since Git 2.29 (2020), which added--object-format=sha256support. GitHub and large forges are gradually rolling out SHA-256 mode. Existing repositories can be converted, but the migration is complex due to the billions of existing commit IDs. For now, SHA-1 commit IDs remain how most Git history is stored, making this tool useful for cross-checking commit object hashes. **Q: Should I migrate from SHA-1 to SHA-256?** A: Yes, for any security-sensitive system. Concrete migration checklist: (1) TLS certificates — if you still have SHA-1-signed certs, replace them immediately; CAs will not issue new ones anyway. (2) API signatures and HMACs — replace with HMAC-SHA-256. (3) Password hashes stored as SHA-1 — migrate to bcrypt or Argon2. (4) Document or package checksums — republish with SHA-256 alongside or replacing SHA-1. (5) Git repositories — opt into SHA-256 mode for new repos if your toolchain supports it. Legacy checksums on archived downloads can remain as-is since they only need to detect accidental corruption. **Q: What was the SHAttered attack?** A: SHAttered (shattered.io, February 2017) was a practical SHA-1 collision produced by Google Security and CWI Amsterdam. The attack cost approximately 110 GPU-years of computation (~$110,000 USD at 2017 cloud prices) and produced two distinct PDF files that produce the same SHA-1 hash: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a. This shattered the assumption that SHA-1 collisions were only theoretical. The attack works by exploiting a differential path in SHA-1's compression function. By 2020, the cost of a chosen-prefix SHA-1 collision had dropped to ~$45,000. Contrast with SHA-256, for which no collision of any kind has ever been found. **Q: Can SHA-1 collisions happen accidentally?** A: Accidentally stumbling on a SHA-1 collision without deliberate effort is still astronomically unlikely — there are 2^160 possible SHA-1 values, so random collision probability is roughly 1 in 10^24 for any two given inputs. The danger is adversarial: a determined attacker can now craft a collision for around $45,000. Accidental corruption of Git history is not a realistic threat from SHA-1 weakness. The real risk is in digitally signed documents, certificates, and code-signing workflows where an attacker could substitute a malicious document with the same hash as a trusted one. **Q: Is SHA-1 OK for non-security uses like checksums?** A: For detecting accidental data corruption — a garbled download, a flipped bit on disk — SHA-1 is technically still adequate, since accidental collisions are still essentially impossible. However, there is little reason to use SHA-1 even for non-security checksums today, because SHA-256 is only marginally slower (hardware-accelerated in all modern CPUs), universally supported, and future-proof. The only legitimate reason to use SHA-1 now is interoperability with a legacy system that only accepts 40-character hex fingerprints. **Q: How long is a SHA-1 hash?** A: A SHA-1 hash is always exactly 160 bits, represented as 40 hexadecimal characters (2 hex chars per byte × 20 bytes). The output length is fixed regardless of input size — hashing a single character or a 10 GB file both produce exactly 40 hex chars. Compare: MD5 produces 32 hex chars (128 bits), SHA-256 produces 64 hex chars (256 bits), and SHA-512 produces 128 hex chars (512 bits). The shorter output relative to SHA-256 is one reason SHA-1's collision resistance is weaker — fewer possible values means collisions are statistically easier to find. **Q: Is my input sent to any server?** A: No. SHA-1 is computed entirely in your browser using the Web Crypto API (crypto.subtle.digest('SHA-1', data)). Open DevTools → Network tab while hashing — you will see zero outgoing requests. Files you drop in are read via the FileReader API and hashed locally; the bytes never leave your machine. This makes the tool safe for hashing confidential documents, legacy certificates, or proprietary source code fingerprints. The same privacy guarantee applies to the SHA-256 generator. **Q: Why does my SHA-1 output differ from sha1sum on the command line?** A: Almost always a trailing newline. The shell commandecho 'hello' | sha1sumincludes a newline (\n) after 'hello', so it hashes 'hello\n' not 'hello'. Useecho -n 'hello' | sha1sumorprintf '%s' 'hello' | sha1sumto strip it. Other common causes: Windows line endings (\r\n vs \n), UTF-8 BOM at the start of the file, or encoding differences (UTF-8 vs Latin-1). This tool encodes input as UTF-8 without BOM before hashing. --- ### SHA-256 Hash Generator & Checksum Tool URL: https://go-tools.org/tools/sha-256-generator Generate SHA-256 hashes online for free. Hash text or files in your browser, verify checksums, and copy 64-character hex output. No signup; data never leaves the page. #### What Is SHA-256? SHA-256 (Secure Hash Algorithm, 256-bit) is the most widely deployed cryptographic hash function in the SHA-2 family, designed by the U.S. National Security Agency and published by NIST in 2001 as part of FIPS 180-2. It takes any input — text, file, or byte stream — and produces a fixed 256-bit (64 hexadecimal character) fingerprint that uniquely identifies the input with cryptographic-grade certainty. SHA-256 has resisted all collision attacks since publication. The NIST FIPS 180-4 specification remains current; it is approved for use by the U.S. federal government, PCI DSS, FIPS 140-3, and the IETF's Internet standards. It underpins TLS certificates (the fingerprint that browsers show in cert dialogs), Git's modern object-ID format (since Git 2.29 in SHA-256 mode), Bitcoin's transaction IDs and proof-of-work, JWT signature verification (the JWS HS256, RS256, ES256 family), and the integrity column of every major package manager (npm, pip, cargo, apt). This tool computes SHA-256 entirely in your browser usingcrypto.subtle.digest('SHA-256', ...)from the Web Crypto API — the same primitive that browsers use internally for TLS handshakes. No bytes are uploaded; no server is involved. The hash you see is exactly what sha256sum, OpenSSL's dgst -sha256, or Python's hashlib.sha256() would produce. When to use SHA-256: file integrity verification, content-addressed storage, digital signature workflows, certificate fingerprinting, cache-busting via content hashing, deduplication. When not to use SHA-256: password storage (use bcrypt, scrypt, or Argon2 — SHA-256 is far too fast for password defense), HMAC without the proper construction (use a dedicated HMAC library), or as a general-purpose random ID (use UUID instead). For comparison: SHA-256 produces 64 hex chars vs. MD5's 32 (broken since 2004), SHA-1's 40 (broken since 2017), SHA-384's 96, and SHA-512's 128. The 256-bit output gives 128 bits of collision resistance — far beyond any foreseeable computational attack. ``` // Hash text using Web Crypto API (SHA-256) async function sha256(text) { const data = new TextEncoder().encode(text); const hash = await crypto.subtle.digest('SHA-256', data); return Array.from(new Uint8Array(hash)) .map(b => b.toString(16).padStart(2, '0')) .join(''); } await sha256('Hello, World!'); // → 'dffd6021bb2bd5b0af676290809ec3a53191dd81c7f70a4b28688a362182986f' ``` #### FAQ **Q: What is SHA-256 and how is it different from MD5 or SHA-1?** A: SHA-256 is a 256-bit cryptographic hash function in the SHA-2 family, designed by the NSA and standardized by NIST in FIPS 180-4. It produces a 64-character hexadecimal output. Unlike MD5 (128-bit, broken since 2004) and SHA-1 (160-bit, broken since 2017), SHA-256 remains cryptographically secure: no practical collision has ever been found. It is the current industry default for digital signatures, certificate fingerprints, blockchain transaction IDs, and integrity verification. **Q: How long is a SHA-256 hash?** A: Always 64 hexadecimal characters (256 bits = 32 bytes, encoded as 2 hex chars per byte). The output length is fixed regardless of input size — a 1-byte input and a 10-GB input both produce 64 hex chars. This fixed length is what makes it useful as a fingerprint. **Q: Is SHA-256 safe for password storage?** A: No. SHA-256 is too fast — a modern GPU can compute billions of SHA-256 hashes per second, which is exactly what an attacker wants for brute-forcing passwords. Use a deliberately slow password hash: bcrypt, scrypt, or Argon2id, each with proper salt and a high cost parameter. SHA-256 is for integrity (verifying data has not been tampered with), not for storing secrets. Use the password generator for the input side; use a dedicated password-hash library on the server. **Q: Can SHA-256 be reversed to find the original input?** A: No. SHA-256 is a one-way function: given a hash, there is no efficient algorithm to recover the input. The only general attack is brute force — trying every possible input and hashing each one. For arbitrary inputs this is computationally infeasible. The exception: short, predictable inputs (common passwords, simple words) can be looked up in rainbow tables, which is why salting passwords matters. **Q: What is the difference between SHA-256 and SHA-2?** A: SHA-2 is the family name; SHA-256 is one specific member. The SHA-2 family also includes SHA-512 (512-bit), SHA-384 (truncated SHA-512), SHA-224 (truncated SHA-256), SHA-512/224, and SHA-512/256. All share the same Merkle-Damgård construction with different word sizes and truncation rules. SHA-256 is the most widely deployed member — it is what TLS, JWT, Git, and Bitcoin all default to. **Q: Is my data sent to a server when I use this tool?** A: No. SHA-256 is computed entirely in your browser using the Web Crypto API (crypto.subtle.digest). Open DevTools → Network tab while hashing — you will see zero outgoing requests. The file you drop in File mode is read with the FileReader API and hashed locally; the bytes never leave your machine. This makes the tool safe for hashing confidential documents, proprietary code, or sensitive checksums. **Q: How do I verify a SHA-256 checksum from a download?** A: 1) Download the file. 2) Open this tool and click the File tab. 3) Drag the file into the dropzone. 4) Wait for the hash to compute (large files take a few seconds). 5) Open the publisher's published SHA256SUMS file. 6) Paste both hashes into the Compare tab — green means match, red means the file is corrupted or tampered. Most Linux distributions, language runtimes (Python, Node.js), and software vendors publish SHA-256 checksums alongside their downloads precisely for this purpose. **Q: Why does my SHA-256 output differ from a command-line tool?** A: Almost always whitespace or encoding. The shell command `echo "hello" | sha256sum` includes a trailing newline (\n), so the hash is for "hello\n" not "hello". Use `echo -n "hello"` to strip it. Other gotchas: Windows line endings (\r\n vs \n), UTF-8 BOM, or the difference between hashing UTF-8 bytes vs UTF-16 bytes. SHA-256 is extremely sensitive — a single byte changes the entire output. **Q: Can SHA-256 hash an empty file?** A: Yes. The SHA-256 of zero bytes is a well-known constant: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. This is sometimes used as a sentinel value or as a quick verification that the hashing pipeline is wired correctly. **Q: Should I use SHA-256 or SHA-512?** A: Use SHA-256 for most cases — it is faster on 32-bit hardware, ubiquitously supported, and provides 128 bits of security against collisions. Use SHA-512 when you are on 64-bit hardware where it is actually faster, or when you specifically need 256 bits of collision resistance for cryptographic protocols that demand it. For everyday use (file checksums, Git, TLS), SHA-256 is the standard. --- ### SHA-3 Hash Generator (Keccak SHA3-256) URL: https://go-tools.org/tools/sha-3-generator Generate SHA-3 hashes online free. NIST FIPS 202 sponge construction — the post-SHA-2 standard. SHA3-256 output in 64 hex chars. Browser-only via lazy-loaded js-sha3; zero uploads. #### What Is SHA-3? SHA-3 (Secure Hash Algorithm 3) is the third generation of NIST's Secure Hash Standard, standardized in FIPS 202 in August 2015. Unlike SHA-1 and SHA-2, which are based on the Merkle-Damgård construction, SHA-3 uses a radically different design called the sponge construction — a choice NIST made deliberately to ensure that a cryptanalytic break of SHA-2 would not automatically compromise SHA-3. The NIST SHA-3 competition (2007–2012): NIST solicited public submissions worldwide in 2007. After three evaluation rounds, 64 candidates were narrowed to five finalists: BLAKE, Grøstl, JH, Keccak, and Skein. In October 2012, Keccak — designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche from STMicroelectronics and NXP Semiconductors — was selected as the winner. All five finalists were considered secure; Keccak's unique sponge-based design gave it the structural diversity NIST prioritized. The sponge construction: SHA-3 absorbs input into a 1600-bit state (the Keccak-f[1600] permutation) in the absorb phase, then squeezes output bits from the state in the squeeze phase. For SHA3-256, the rate/capacity split is 1088/512 bits. Because only 256 of the 1600 internal state bits appear in the output, an attacker cannot reconstruct the full state from the hash — making length-extension attacks structurally impossible. This contrasts with SHA-256, where the full internal state is exposed in the output, requiring HMAC to prevent length-extension. SHA-3 vs. Keccak — the padding difference: NIST modified the original Keccak submission by changing the domain separation padding from0x01to0x06. This means NIST SHA3-256 and original Keccak-256 produce different 64-hex-character outputs for every input. This is not a theoretical concern — it is why Ethereum'skeccak256(frozen before FIPS 202 was finalized) differs from this tool's SHA3-256 output for the same string. Never use this tool to replicate Ethereum address derivation. FIPS 202 defines four SHA-3 variants: SHA3-224 (56 hex chars), SHA3-256 (64 hex chars), SHA3-384 (96 hex chars), SHA3-512 (128 hex chars). This tool implements SHA3-256, the most common variant and the one most directly comparable to SHA-256. Library note: SHA-3 is not yet in the browser's Web Crypto API spec (crypto.subtlesupports SHA-1, SHA-256, SHA-384, SHA-512 only). This tool lazy-loads thejs-sha3JavaScript library (~10 KB gzipped) on first use. After that single download, all computation runs locally in your browser — no input data is ever transmitted. When to use SHA-3: new protocols requiring structural diversity from SHA-2; keyed MACs without the HMAC wrapper (KMAC128/256 per NIST SP 800-185); post-quantum hedging as a SHA-2 backup; compliance with systems that mandate FIPS 202. When to stick with SHA-256: universal library support, hardware acceleration (SHA-NI extensions), existing protocol compatibility, and most everyday integrity use cases where SHA-256 is already the established standard. ``` // SHA-3 (NIST FIPS 202 SHA3-256) using js-sha3 library import { sha3_256 } from 'js-sha3'; const hash = sha3_256('Hello, World!'); // → '882f4b6991a775295186a4e3cc5ece9fc0b618c8c3e7a7beafdd0f56f13ae43b' // Note: this differs from Ethereum's keccak256 for the same input: // keccak256('Hello, World!') = 'acaf3289d7b601cbd114fb36c4d29c85bbfd5e133f14cb355c3fd8d99367964f' // The difference is the padding byte: 0x06 (SHA-3) vs 0x01 (original Keccak) ``` #### FAQ **Q: Is SHA-3 the same as Keccak?** A: Close, but not identical. SHA-3 is based on the Keccak algorithm, which won the 2007-2012 NIST SHA-3 competition, but NIST changed the padding rule during standardization. Original Keccak appends a0x01suffix byte before padding; NIST SHA-3 (FIPS 202, 2015) appends0x06. This single-byte difference means SHA3-256 and Keccak-256 produce different 64-character outputs for every input. The algorithms are structurally identical otherwise — same Keccak-f[1600] permutation, same sponge construction. When someone says "Keccak" in the Ethereum/blockchain context, they almost always mean the original pre-FIPS padding variant, not NIST SHA-3. **Q: Why does Ethereum use keccak256, not SHA-3?** A: Ethereum was designed in 2013–2014 and launched in 2015 — before NIST finalized SHA-3 in August 2015. When Ethereum's protocol was frozen, the Keccak team's original proposal was the reference implementation. NIST then changed the padding during standardization, but Ethereum could not retroactively adopt the FIPS 202 variant without breaking consensus (every node must compute identical hashes). The result is a permanent fork: Ethereum'skeccak256uses the original Keccak padding (0x01), while this tool's SHA3-256 uses the NIST FIPS 202 padding (0x06). Same structural algorithm, different outputs. Never use this tool to replicate Ethereum address derivation or EVM keccak256 — you will get wrong results. **Q: What is the sponge construction?** A: The sponge construction is SHA-3's alternative to SHA-2's Merkle-Damgård chaining. Instead of compressing input block-by-block into a running hash state (Merkle-Damgård), the sponge has two phases: absorb (input is XORed into a portion of the state and mixed with the Keccak-f[1600] permutation repeatedly) and squeeze (output bits are read from the state). The critical security benefit: the internal state is larger than the output — SHA3-256 uses a 1600-bit state but only outputs 256 bits, leaving 1344 bits of hidden state. An attacker who sees only the 256-bit output cannot reconstruct the full state to extend the message, making length-extension attacks structurally impossible without a wrapper. This differs from SHA-256, which requires HMAC to prevent length-extension. **Q: Should I use SHA-3 instead of SHA-2?** A: Not by default — both SHA-256 and SHA3-256 are currently secure and NIST-approved. SHA-3 is designed as a structural backup for SHA-2: because they use completely different designs (Merkle-Damgård vs. sponge), a break in one algorithm does not compromise the other. Use SHA-3 when: (1) your protocol explicitly requires it, (2) you need length-extension immunity without the HMAC wrapper, (3) you are building a new system that wants future-proof algorithm agility, or (4) your organization mandates a SHA-3 backup hash alongside SHA-256. For everyday file checksums and certificate fingerprints, SHA-256 remains the universal standard with better library and hardware support. **Q: Is SHA-3 faster than SHA-256?** A: In software, usually slower. SHA3-256 typically achieves 150–400 MB/s in browser JavaScript, compared to 400–700 MB/s for SHA-256 via the Web Crypto API (which uses the browser's native, C-level SHA-2 implementation). In dedicated hardware and ASICs (e.g., custom security chips), SHA-3's Keccak-f[1600] permutation is often faster because it parallelizes better and uses only simple bitwise operations (XOR, AND, rotate) — no modular addition. SHA-3 also outperforms SHA-2 on 32-bit embedded hardware in many cases. For browser-based tools this performance gap is imperceptible; for bulk file hashing it matters. **Q: How long is a SHA-3 hash from this tool?** A: This tool defaults to SHA3-256, which always produces exactly 64 hexadecimal characters (256 bits = 32 bytes, 2 hex chars per byte). NIST FIPS 202 also defines SHA3-224 (56 hex chars), SHA3-384 (96 hex chars), and SHA3-512 (128 hex chars). All share the same Keccak-f[1600] permutation; only the capacity/rate split and output length differ. For comparison: SHA-256 also produces 64 hex chars, but they are different 64-character strings for the same input. **Q: Is SHA-3 quantum-resistant?** A: Partially. Grover's algorithm on a quantum computer can square-root the search space of any hash function, effectively halving the security level. SHA3-256 has 256 bits of pre-image resistance, which is reduced to 128 bits under a quantum attack — still secure under any near-term threat model. The important advantage over SHA-2: SHA-3's sponge construction is unrelated to Merkle-Damgård, so it is unaffected by any cryptanalytic technique specific to SHA-2's compression function. NIST's post-quantum guidance recommends SHA-3 as the preferred hash for new protocols that want design diversity alongside SHA-2. **Q: Is my data sent to a server when I use this tool?** A: No. After the initial library load (thejs-sha3script is fetched once from a CDN, ~10 KB), all hashing runs entirely in your browser in JavaScript. Open DevTools → Network tab while hashing text — you will see zero outgoing requests carrying your input data. Unlike the SHA-2 tools on this site (which use the browser-built-in Web Crypto API), SHA-3 is not yet in the Web Crypto spec, so a JavaScript library is required. The library download is the only network request; your text never leaves the page. See also: the SHA-256 generator and MD5 generator use no external library at all. **Q: What was the NIST SHA-3 competition?** A: NIST ran an open competition from 2007 to 2012 to select a third Secure Hash Algorithm standard — not to replace SHA-2 (which remains secure), but to diversify the hash algorithm landscape in case SHA-2 was ever broken. 64 initial submissions were narrowed to 5 finalists: BLAKE, Grøstl, JH, Keccak, and Skein. Keccak, designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche (from STMicroelectronics and NXP Semiconductors), was selected as the winner in October 2012 and standardized as SHA-3 in NIST FIPS 202 in August 2015. Its selection was notable for choosing a fundamentally different design from SHA-2 rather than an evolutionary variant. **Q: Is SHA-3 vulnerable to length-extension attacks?** A: No — by design. Length-extension attacks exploit the fact that Merkle-Damgård constructions (SHA-256, SHA-512, MD5) expose the internal state in the hash output, allowing an attacker to append data to a hashed message without knowing the secret prefix. SHA-3's sponge construction avoids this entirely: the 1600-bit internal state is larger than the 256-bit output, so the output does not reveal enough state to extend the message. This means you can use plain SHA3-256 as a keyed MAC primitive (KMAC) safely, whereas using raw SHA-256 as a keyed MAC (HASH(key || message)) is insecure without the HMAC wrapper. --- ### SHA-384 Hash Generator (TLS Suite B Hash) URL: https://go-tools.org/tools/sha-384-generator Generate SHA-384 hashes online — 96-character hex output, length-extension immune, NSA Suite B compliant. Paired with AES-256-GCM in TLS. All hashing runs in your browser via Web Crypto API. #### What Is SHA-384? SHA-384 is a 384-bit cryptographic hash function in the SHA-2 family, published by NIST in 2001 as part of FIPS 180-2. It is architecturally a truncated variant of SHA-512: both algorithms use identical 64-bit word arithmetic, 80 compression rounds, and 1024-bit input blocks — the only differences are the initialization vector (IV) and the fact that SHA-384 discards the last 128 bits of SHA-512's 512-bit output, producing 384 bits (96 hexadecimal characters). Why the truncation matters cryptographically: SHA-256 is vulnerable to length-extension attacks — given SHA-256(message), an attacker can compute SHA-256(message || padding || extension) without knowing the original message, by resuming the hash computation from the leaked internal state. SHA-384 eliminates this attack surface: the truncation discards 128 bits of internal state, so the published 384-bit hash does not carry enough information to resume the SHA-512 computation. This makes raw SHA-384 (without HMAC wrapping) safe for constructions where the hash output may be exposed to adversaries. NSA Suite B and TLS role: SHA-384 was mandated by NSA Suite B (CNSSP-15, 2005) for TOP SECRET classification. It is the hash algorithm in the ciphersuite ECDHE-ECDSA-AES256-GCM-SHA384, which is the standard TLS 1.2 ciphersuite for Suite B compliant systems and remains widely deployed in U.S. government, financial, and defense networks. The NSA's CNSA Suite (2015) retained SHA-384 alongside SHA-256, and SHA-384 appears in TLS 1.3's signature algorithms list (ecdsa_secp384r1_sha384). Performance: On 64-bit hardware SHA-384 and SHA-512 run at identical speed — both use 64-bit word operations exclusively. They are typically faster than SHA-256 (which uses 32-bit word operations and requires more passes for the same input) on modern x86-64 and ARM64 processors. This tool computes SHA-384 entirely in your browser viacrypto.subtle.digest('SHA-384', ...)from the Web Crypto API. The output is bit-for-bit identical to whatsha384sum,openssl dgst -sha384, or Python'shashlib.sha384()produce. When to use SHA-384: TLS ciphersuites mandating Suite B compliance, HMAC-SHA-384 for TLS 1.2 PRF, HKDF-SHA-384 key derivation, classified document fingerprinting, and any context where length-extension immunity is required without HMAC wrapping. When not to use SHA-384: general-purpose checksums and everyday integrity use — SHA-256 is the standard choice for those, with simpler library support and universal tool compatibility. ``` // Hash text using Web Crypto API (SHA-384) async function sha384(text) { const data = new TextEncoder().encode(text); const hash = await crypto.subtle.digest('SHA-384', data); return Array.from(new Uint8Array(hash)) .map(b => b.toString(16).padStart(2, '0')) .join(''); } await sha384('Hello, World!'); // → '5485cc9b3365b4305dfb4e8337e0a598a574f8242bf17289e0dd6c20a3cd44a089de16ab4ab308f63e44b1170eb5f515' ``` #### FAQ **Q: Why use SHA-384 over SHA-256?** A: Two reasons: length-extension immunity and Suite B compliance. SHA-384 is immune to length-extension attacks because truncating SHA-512's 512-bit state to 384 bits discards 128 bits of internal state — an attacker who knows SHA-384(message) cannot compute SHA-384(message || extension) without knowing the full message. SHA-256 is vulnerable to length-extension attacks, which is why keyed use of SHA-256 requires HMAC construction. Additionally, SHA-384 was required by NSA Suite B at the TOP SECRET level and remains prevalent in TLS ciphersuites (ECDHE-ECDSA-AES256-GCM-SHA384) and government systems transitioning to the CNSA Suite. **Q: Is SHA-384 as secure as SHA-512?** A: Yes, in terms of collision resistance. SHA-384 provides 192 bits of collision resistance (half of 384 bits) versus SHA-512's 256 bits — both are far beyond any foreseeable attack. SHA-384 provides the same second-preimage resistance as SHA-512 in practice. The only meaningful difference is output length: 96 hex chars vs 128 hex chars. If you need maximum collision resistance for extremely long-lived archives (beyond 50 years), SHA-512 provides a larger margin — but for any current system, SHA-384 is fully adequate. **Q: Is SHA-384 the same speed as SHA-512?** A: Yes — they are literally the same algorithm. SHA-384 is SHA-512 with a different initialization vector (IV) and the output truncated to the first 384 bits. Because both use 64-bit word arithmetic throughout, they run at identical speed on 64-bit hardware. Counterintuitively, SHA-384 and SHA-512 are both typically faster than SHA-256 on 64-bit machines — SHA-256 uses 32-bit word arithmetic and processes 512-bit blocks, while SHA-512 processes 1024-bit blocks in fewer passes. Typical throughput: 500–900 MB/s in a browser, comparable to native tools. **Q: When does HMAC-SHA-384 matter over HMAC-SHA-256?** A: In TLS 1.2 handshakes negotiated with SHA-384 ciphersuites, the PRF is HMAC-SHA-384 — this is a hard protocol requirement, not a choice. Outside of TLS, prefer HMAC-SHA-384 when: (1) you are targeting Suite B / CNSA compliance, (2) the system handles data classified above SECRET, or (3) you want an extra margin against future advances against 128-bit security. For general-purpose MACs where neither applies, HMAC-SHA-256 is standard and well-tested across libraries. **Q: Should I use SHA-384 for general-purpose hashing?** A: Not unless you have a specific reason. SHA-256 is the industry default for file integrity, checksums, Git objects, JWT signatures, and certificate fingerprints — it is universally supported and provides 128 bits of collision resistance, more than enough for any practical use. SHA-384 makes sense when you need (1) length-extension immunity without HMAC wrapping, (2) Suite B / CNSA compliance, or (3) interoperability with TLS ciphersuites that mandate SHA-384. For everything else, SHA-256 is simpler and equally secure. **Q: What is NSA Suite B and is it still used?** A: NSA Suite B was a set of cryptographic algorithms approved for protecting U.S. classified information, published by the NSA in 2005 (CNSSP-15). Suite B required SHA-256 for SECRET and SHA-384 for TOP SECRET. In 2015 the NSA announced a transition away from Suite B toward the Commercial National Security Algorithm Suite (CNSA), driven by post-quantum cryptography concerns — Suite B's elliptic curve algorithms (P-256, P-384) could eventually be broken by a sufficiently large quantum computer. However, SHA-384 was retained in CNSA alongside SHA-256. Many government and defense systems built for Suite B compliance still use SHA-384, and TLS ciphersuites originally required by Suite B (like ECDHE-ECDSA-AES256-GCM-SHA384) remain widely deployed in government networks. **Q: How long is a SHA-384 hash?** A: Always exactly 96 hexadecimal characters — 384 bits divided into 48 bytes, each byte encoded as two hex characters. The output length is fixed regardless of input size; a 1-byte message and a 10 GB file both produce 96 hex chars. Compare: SHA-256 produces 64 hex chars, SHA-512 produces 128 hex chars, MD5 produces 32 hex chars. The 96-character output is the immediate signal that a hash was produced by SHA-384. **Q: Is my data sent to a server when I use this tool?** A: No. SHA-384 is computed entirely in your browser using the Web Crypto API (crypto.subtle.digest('SHA-384', data)). Open DevTools → Network tab while hashing — you will see zero outgoing requests. Files you drop in are read via the FileReader API and hashed locally; the bytes never leave your machine. This makes the tool safe for hashing classified document fingerprints, TLS private key material, or any other sensitive input. The same privacy guarantee applies to the SHA-256 generator and SHA-512 generator. --- ### SHA-512 Hash Generator (512-bit SHA-2) URL: https://go-tools.org/tools/sha-512-generator Generate SHA-512 hashes online — 128 hex chars output, faster than SHA-256 on 64-bit CPUs. Ideal for long-term archives, LUKS key derivation, and HMAC-SHA-512. Browser-only, zero uploads. #### What Is SHA-512? SHA-512 (Secure Hash Algorithm, 512-bit) is the full-width member of the SHA-2 family, published by NIST in 2001 in FIPS 180-2. It takes any input — text, file, or byte stream — and produces a fixed 512-bit (128 hexadecimal character) fingerprint. SHA-512 shares the same Merkle-Damgård construction as its siblings but operates on 1024-bit input blocks with 80 compression rounds and 64-bit word arithmetic, versus SHA-256's 512-bit blocks, 64 rounds, and 32-bit words. The 64-bit performance advantage: On modern x86-64 and ARM64 hardware, SHA-512's 64-bit word operations map directly to CPU register widths. SHA-256's 32-bit operations, by contrast, require additional passes to process the same data. The practical result: SHA-512 is typically faster than SHA-256 on any 64-bit CPU — usually 600–1,000 MB/s vs. 400–700 MB/s in a browser. This counterintuitive performance advantage makes SHA-512 the preferred choice in performance-sensitive 64-bit applications that also need the stronger collision resistance. Collision resistance: SHA-512 provides 256 bits of collision resistance — twice the 128-bit resistance of SHA-256. This larger margin is why institutional archives, long-lived digital signatures, and military-grade systems prefer SHA-512: data that must remain tamper-evident for 30–50 years benefits from the extra headroom against future cryptanalytic advances and quantum computing (Grover's algorithm halves the effective security level, leaving 256-bit pre-image resistance intact). Key use cases: LUKS disk encryption key derivation (PBKDF2-SHA-512 is the LUKS2 default), Apple HFS+ filesystem integrity checksums, HMAC-SHA-512 in high-assurance APIs and hardware security modules, HKDF-SHA-512 key expansion, and long-term archive manifests for government and institutional records. SHA-512/256 — the truncated NIST variant: FIPS 180-4 (2015) standardized SHA-512/256 as a separate algorithm: it uses SHA-512's 64-bit arithmetic and 1024-bit blocks but a different initialization vector, producing a 256-bit output. SHA-512/256 is length-extension resistant (unlike plain SHA-256) and faster than SHA-256 on 64-bit hardware. It is a distinct algorithm from straight SHA-512; this tool computes full SHA-512 (128 hex chars). This tool computes SHA-512 entirely in your browser viacrypto.subtle.digest('SHA-512', ...). The output is bit-for-bit identical tosha512sum,openssl dgst -sha512, and Python'shashlib.sha512(). Related tools: SHA-256 Generator (64 hex chars, 128-bit collision resistance, fastest on 32-bit), SHA-384 Generator (96 hex chars, Suite B TLS, length-extension immune), SHA-3 Generator (Keccak sponge construction — different design from SHA-2 entirely). ``` // Hash text using Web Crypto API (SHA-512) async function sha512(text) { const data = new TextEncoder().encode(text); const hash = await crypto.subtle.digest('SHA-512', data); return Array.from(new Uint8Array(hash)) .map(b => b.toString(16).padStart(2, '0')) .join(''); } await sha512('Hello, World!'); // → '374d794a95cdcfd8b35993185fef9ba368f160d8daf432d08ba9f1ed1e5abe6cc69291e0fa2fe0006a52570ef18c19def4e617c33ce52ef0a6e5fbe318cb0387' ``` #### FAQ **Q: Why use SHA-512 over SHA-256?** A: Two main reasons: greater collision resistance and better performance on 64-bit hardware. SHA-512 provides 256 bits of collision resistance vs. SHA-256's 128 bits — meaningful when data must remain tamper-evident for decades or when a protocol demands maximum cryptographic margin. On 64-bit CPUs (virtually all modern hardware), SHA-512 is also typically faster than SHA-256 because its 64-bit word arithmetic matches the CPU's native register width; SHA-256 uses 32-bit words and processes smaller 512-bit blocks, requiring more passes for the same input. If you are on 64-bit hardware and need the extra margin, SHA-512 is the natural upgrade. **Q: Is SHA-512 faster than SHA-256?** A: Yes — on 64-bit hardware. SHA-512 uses 64-bit word arithmetic and processes 1024-bit (128-byte) blocks; SHA-256 uses 32-bit words and 512-bit (64-byte) blocks. On x86-64 and ARM64 processors, native 64-bit operations run at the same cost as 32-bit operations, so SHA-512 hashes approximately twice the data per clock cycle compared to SHA-256. Typical throughput: SHA-512 at 600–1,000 MB/s vs. SHA-256 at 400–700 MB/s in browsers using the Web Crypto API. On 32-bit hardware the relationship reverses — 64-bit arithmetic requires emulation, making SHA-512 slower. See also: SHA-384 runs at identical speed to SHA-512 on 64-bit hardware. **Q: How long is a SHA-512 hash?** A: Always exactly 128 hexadecimal characters — 512 bits divided into 64 bytes, each byte encoded as two hex characters. The output is fixed-length regardless of input size: a single character and a 10 GB file both produce 128 hex chars. Compare: SHA-256 produces 64 chars, SHA-384 produces 96 chars, MD5 produces 32 chars, SHA-1 produces 40 chars. The 128-character length is the immediate visual signal that a hash was produced by SHA-512. **Q: Is SHA-512 truncation (SHA-512/256) safe?** A: Yes. NIST standardized SHA-512/256 in FIPS 180-4 as a first-class hash variant — not a workaround, but a deliberate design. SHA-512/256 uses a different initialization vector than straight SHA-512 (to prevent related-key weaknesses) and truncates the output to 256 bits. The truncation also eliminates length-extension vulnerabilities present in plain SHA-256, since the discarded 256 bits of state cannot be recovered from the published output. SHA-512/256 is therefore strictly safer than SHA-256 against length-extension attacks while offering the same 128-bit collision resistance — and running faster on 64-bit hardware. Note: SHA-512/256 is a distinct algorithm from straight SHA-512; this tool computes full SHA-512 (128 hex chars), not the truncated variant. **Q: Should I use SHA-512 for password storage?** A: No. SHA-512, like all SHA-2 variants, is designed to be fast — and fast is exactly wrong for password storage. A modern GPU can compute hundreds of millions of SHA-512 hashes per second, making brute-force attacks against a leaked database practical. For passwords, use a deliberately slow algorithm: bcrypt (2^cost iterations), scrypt (memory-hard), or Argon2id (memory-hard, time-hard, winner of the Password Hashing Competition). Many of these use HMAC-SHA-512 internally as a building block, but the slow iteration is what provides the security. Use SHA-512 for data integrity and message authentication; use bcrypt/scrypt/Argon2id for passwords. **Q: Does SHA-512 leak timing on short inputs?** A: No more than any other hash function. SHA-512 always processes a minimum of one 1024-bit block regardless of input size (due to Merkle-Damgård padding), so the computation time for very short inputs is essentially constant. The variation in timing comes from the number of full 1024-bit blocks the input fills — larger inputs take longer in direct proportion to size, not in a way that leaks content. For verifying two hashes in code, the timing concern is in the comparison step, not the hashing step: always use constant-time comparison (Node.jscrypto.timingSafeEqual(), Pythonhmac.compare_digest()). **Q: Is SHA-512 quantum-resistant?** A: Partially. Grover's algorithm on a quantum computer can search an unsorted database of N items in √N steps, which effectively halves the security level of any hash function. SHA-512's 256-bit collision resistance would be reduced to 128 bits — still secure under any credible near-term threat model. For comparison, SHA-256's 128-bit collision resistance would be reduced to 64 bits, which is more concerning. NIST's post-quantum guidance (NIST IR 8105) recommends SHA-512 (or SHA-3-512) for applications requiring long-term security against quantum-capable adversaries. For maximum future-proofing, consider also exploring SHA-3, which uses a different construction (Keccak sponge) resistant to attacks that target Merkle-Damgård designs. **Q: Is my data sent to a server when I use this tool?** A: No. SHA-512 is computed entirely in your browser using the Web Crypto API (crypto.subtle.digest('SHA-512', data)). Open DevTools → Network tab while hashing — you will see zero outgoing requests. Files you drop in are read via the FileReader API and hashed locally; the bytes never leave your machine. This makes the tool safe for hashing sensitive documents, private keys, or confidential data. The same privacy guarantee applies to the SHA-256 generator and SHA-384 generator. --- ### URL Slug Generator — Slugify Any Text URL: https://go-tools.org/tools/slug-generator Slugify any title into a clean, SEO-friendly URL slug instantly. Transliterate accents and Cyrillic, or keep Unicode letters. 100% private, in your browser. #### What Is a URL Slug? A URL slug is the part of a web address that identifies a specific page in a human-readable way. In `https://go-tools.org/blog/how-to-write-url-slugs`, the slug is `how-to-write-url-slugs` — the segment after the last slash that names the content. The word comes from newspaper publishing, where a "slug" was the short working name editors gave a story; the web borrowed the term for the short name that identifies a page. A well-formed slug follows a few conventions that have become near-universal. It's lowercase, because search engines treat URLs as case-sensitive and a consistent lowercase form prevents the same page from being reachable at multiple URLs. It uses hyphens to separate words, because Google reads a hyphen as a word boundary (so `url-slug-generator` is three keywords) but reads an underscore as a word joiner. It strips punctuation and symbols, because characters like `?`, `&`, `#`, and spaces have reserved meanings in URLs or must be percent-encoded, which makes the address ugly and harder to share. And it's concise — long enough to describe the page and carry the target keyword, short enough to read at a glance. Generating a slug by hand is mechanical but tedious: lowercase the title, replace spaces with hyphens, remove punctuation, fold accented characters, collapse any doubled hyphens, and trim the ends. This tool does all of that in one step, on every keystroke. The interesting decisions are around non-ASCII text. There are two valid philosophies. The first, transliteration (this tool's ASCII mode), converts é to e, ü to u, ß to ss, and Привет to privet, producing a portable pure-ASCII slug that works everywhere. It relies on Unicode NFD normalization to split an accented letter into a base letter plus a combining mark, then discards the mark — a zero-dependency technique built into every JavaScript engine — plus small hand-maintained tables for characters that have no decomposition (ß, æ, ø) and for the Cyrillic and Greek alphabets. The second philosophy, Unicode preservation (this tool's Unicode mode), keeps letters from every script and only lowercases and hyphenates, producing an internationalized slug like 你好-世界. This is exactly the rule GitHub applies when it turns a Markdown heading into an anchor link, and modern browsers and search engines support it fully through the IRI standard. The slug is one small piece of URL design, but it does real work: it tells human visitors what a page is about before they click, it gives search engines keyword signals, and it makes links readable when shared in chat, email, or social posts. A descriptive slug like /tools/url-slug-generator beats an opaque one like /tools/page?id=4823 on every one of those dimensions. This tool runs entirely in your browser — the slug updates with no network request, and your text is never uploaded or logged. For related text work, the case converter switches text between camelCase, snake_case, kebab-case and other identifier styles, the URL encoder/decoder handles percent-encoding of full URLs and query strings, and the word counter measures length and reading time. Together they cover most of the text-shaping a developer or content author does before publishing. ``` // The core of a zero-dependency slugify (ASCII mode) function slugify(input) { return input .normalize('NFD') // café → cafe + combining accent .replace(/[\u0300-\u036f]/g, '') // drop the combining marks .replace(/ß/g, 'ss') // chars with no NFD decomposition .replace(/&/g, ' and ') // keep the meaning of '&' .toLowerCase() .replace(/[^a-z0-9]+/g, '-') // every other run of junk → one hyphen .replace(/^-+|-+$/g, ''); // trim leading / trailing hyphens } slugify('Crème Brûlée Recipe'); // 'creme-brulee-recipe' slugify('Salt & Pepper'); // 'salt-and-pepper' slugify('10 Tips: A Guide!'); // '10-tips-a-guide' ``` #### FAQ **Q: What is a URL slug?** A: A URL slug is the human-readable identifier at the end of a web address that names a specific page — in `https://go-tools.org/blog/url-slug-best-practices`, the slug is `url-slug-best-practices`. Slugs are lowercase, use hyphens instead of spaces, strip punctuation, and ideally contain the page's target keywords. A good slug is short, descriptive, and stable (it shouldn't change after publishing, because changing it breaks every existing link). This tool converts any title or phrase into that form automatically, so you don't have to lowercase, hyphenate, and strip characters by hand. **Q: Should I use hyphens or underscores in a URL slug?** A: Use hyphens. Google has stated for years that it treats hyphens as word separators in URLs but treats underscores as word joiners — so `url-slug-generator` is read as three words ("url", "slug", "generator") while `url_slug_generator` can be read as one token. Hyphens are the universal convention across WordPress, Ghost, Hugo, and virtually every modern CMS. This tool defaults to hyphens for that reason, but offers an underscore option for the cases where a downstream system requires it (some file naming schemes and legacy databases). **Q: What is the difference between ASCII mode and Unicode mode?** A: ASCII mode transliterates every non-ASCII character to its closest Latin equivalent and drops anything it can't convert, producing a pure a–z, 0–9 slug: café → cafe, Привет → privet, 你好 → (dropped). It's the safest, most portable option and what most CMS platforms expect. Unicode mode keeps letters from any script (Chinese, Arabic, Cyrillic, Greek) and only lowercases and hyphenates, producing an internationalized slug like 你好-世界 — the same rule GitHub uses for heading anchors. Use ASCII mode by default; use Unicode mode when your URLs are meant for readers of a non-Latin script and you want the original characters preserved. **Q: Are Unicode (non-ASCII) URL slugs safe and good for SEO?** A: Yes, with caveats. Modern browsers display Unicode characters in URLs (the IRI standard, RFC 3987) and transparently percent-encode them on the wire, and Google indexes and ranks them correctly — a slug like /статьи/привет is fully supported. The trade-offs: when copied as plain text the URL may appear percent-encoded (%D0%BF%D1%80...), which looks ugly, and some older systems or analytics tools handle the encoding imperfectly. The rule of thumb: if your audience reads the script natively, Unicode slugs improve readability and click-through; if your audience is international or you want maximum compatibility, ASCII transliteration is the safer choice. **Q: How are emojis and special symbols handled?** A: Emojis and pictographic symbols are removed in both modes, because they are not letters or digits and have no place in a clean URL. So "🚀 Launch Day" becomes `launch-day` in either mode. Among punctuation, the ampersand (&) is a special case: it's expanded to the word "and" by default so you don't silently lose meaning ("Salt & Pepper" → `salt-and-pepper`). Everything else — colons, slashes, quotes, percent signs, parentheses — is treated as a separator and collapsed into a single hyphen, so runs of punctuation never produce doubled separators. **Q: What's a good maximum length for a slug?** A: There's no hard limit, but shorter is better. Most SEO practitioners aim for slugs under about 60 characters or roughly 3–6 meaningful words — long enough to be descriptive and contain the target keyword, short enough to read at a glance and not get truncated in search results or when shared. This tool's Max length option truncates at a word boundary (it won't cut a word in half) so you can cap a long title cleanly. Set it to 0 to keep the full slug. Remember that stop words (a, the, of, for) can usually be dropped without hurting clarity, which is the easiest way to shorten a slug. **Q: How does the tool handle Chinese, Japanese, Korean, or Arabic text?** A: It depends on the mode. In ASCII mode, CJK ideographs and Arabic script have no built-in transliteration here, so they're dropped and you may get an empty slug — ASCII mode is designed for Latin, Cyrillic, and Greek source text. In Unicode mode, the characters are preserved: 你好 世界 becomes 你好-世界 and مرحبا بالعالم keeps its Arabic letters, lowercased and hyphenated. For CJK and Arabic audiences, Unicode mode is the right choice. (Full pinyin or romaji transliteration of Chinese and Japanese is a deliberately out-of-scope feature, because it requires large dictionaries and produces ambiguous results.) **Q: Should a URL slug include the date or a number?** A: Generally avoid putting dates in the slug itself. A slug like /2024-best-laptops ages badly — when you update the article in 2026 you either keep a misleading 2024 in the URL or change the slug and break inbound links. Keep dates out of the slug and let your CMS store the publish date separately. Numbers that are part of the meaning (list counts like "10 tips", version numbers, model numbers) are fine and often valuable for click-through — this tool preserves digits, so "10 Tips for X" keeps the "10". The principle is: include numbers that are part of the topic, exclude dates that will go stale. **Q: Is my text uploaded anywhere?** A: No. Every slug is generated 100% in your browser with JavaScript. Your text is never transmitted, never stored on any server, never logged, and never analyzed. You can verify in your browser's Network tab — typing in the editor or clicking Copy triggers zero network requests. This makes the tool safe for unannounced product names, draft article titles, internal document names, and any other confidential material. The shareable link feature encodes your input into the URL only in your own browser; nothing is sent anywhere until you choose to share that link. --- ### Sort Text Lines Alphabetically & Naturally URL: https://go-tools.org/tools/sort-text-lines Sort text lines alphabetically, numerically (natural order), or by length — ascending or descending. Free online line sorter, 100% in your browser. Also dedupe, reverse, and clean up lists. No signup, nothing uploaded. #### What Does Sorting Text Lines Mean? Sorting text lines means taking a block of text split on newlines and reordering those lines according to a rule — most commonly alphabetical (dictionary) order, but also numeric order, length, or reverse. It is one of the most frequent small tasks in a developer's or writer's day: alphabetizing a list of names, ordering import statements, tidying a column of tags copied from a spreadsheet, or arranging config keys so a diff stays clean. The subtlety that trips people up is that computers sort strings by character code by default, not by human intuition. A plain sort places `item10` before `item2` because the character `1` has a lower code point than `2`. It also pushes every capitalized word ahead of lowercase ones, so `Zebra` lands before `apple`. Real-world lists rarely want either behavior. This tool defaults to case-insensitive, locale-aware sorting and offers a Natural method that compares embedded numbers as numbers — the two settings that make sorting match what a human expects. Sorting is closely related to cleaning a list. You often want to sort and deduplicate together, or drop blank lines and stray whitespace in the same pass. This tool folds those operations into one panel: sort, remove duplicates, trim, remove empty lines, reverse, and even shuffle. For deduplication as the primary task — with control over keeping the first or last occurrence — reach for the companion Remove Duplicate Lines tool, which shares the same engine. To count words and lines, use the Word Counter; to compare two versions of a list, use Text Diff; and to change the casing of your lines, use the Case Converter. Everything happens entirely in your browser with no uploads, so sorting a confidential list is exactly as private as opening a text editor. Paste, choose an order, and copy the result — the whole round trip takes a couple of seconds. ``` Input (unsorted): file10.txt file2.txt file1.txt Alphabetical sort (naive): file1.txt file10.txt ← wrong: 10 before 2 file2.txt Natural sort (numeric-aware): file1.txt file2.txt file10.txt ← correct ``` #### FAQ **Q: What does this tool do?** A: It sorts lines of text right in your browser — alphabetically, in natural (numeric-aware) order, or by length, ascending or descending. As you paste or type, the sorted result appears instantly with a live count of lines in and out. You can also deduplicate, reverse, trim, remove empty lines, add line numbers, or shuffle in the same pass. Nothing is uploaded: all sorting runs 100% client-side in JavaScript, so it is safe for confidential lists, internal wordlists, and any data you would not want to send to a server. You can confirm this in your browser's Network tab — sorting triggers zero network requests. **Q: What's the difference between alphabetical and natural sort?** A: Alphabetical (lexical) sort compares strings one character at a time, so `file10` comes before `file2` because the character `1` (U+0031) sorts before `2` (U+0032). Natural sort recognizes runs of digits and compares them as numbers, so `file2` correctly precedes `file10`. Use alphabetical for plain words and codes; use natural for anything with embedded numbers — filenames, version tags (`v1.2` vs `v1.10`), invoice numbers, and numbered list items. This tool implements natural sort with `Intl.Collator({ numeric: true })`, the standards-based Unicode collation built into every modern browser. **Q: How do I alphabetize a list?** A: Paste your list, keep the default Ascending order with the Alphabetical method, and the lines are put in alphabetical order (A→Z) instantly — that's all it takes to alphabetize a list online. For names, tags, or keywords, leave Case-sensitive off so capitalized and lowercase entries sort together instead of splitting into two runs. Switch to Descending for Z→A, or enable Remove duplicate lines to alphabetize and dedupe in one step. Everything runs in your browser, so you can put even a confidential list in alphabetical order without uploading it. **Q: Is my text uploaded anywhere?** A: No. Every operation — sorting, deduplication, trimming, reversing — runs entirely in your browser using JavaScript. Your text is never transmitted, never stored on any server, never logged, and never analyzed. This makes the tool safe for confidential lists, internal data, security wordlists, and any content you would not paste into a networked service. There are no cookies used for your input and no third-party analytics that capture what you type. Open your browser's developer tools and watch the Network tab: sorting a million-line list produces zero requests. **Q: How do I sort a list of numbers correctly?** A: Choose the Natural method. Plain alphabetical sort treats numbers as text, so `100` would sort before `2` (because `1` < `2` as characters). Natural sort compares the numeric value, giving `2`, `100` in the right order. For lines that mix text and numbers like `chapter 2` and `chapter 12`, natural sort also gets it right by comparing the `2` and `12` numerically. If your lines are purely numeric and you want strict numeric ordering, natural sort handles integers and the numeric portions of mixed strings; for decimal-heavy financial data, double-check edge cases like leading zeros. **Q: Does sorting respect uppercase and lowercase?** A: By default, no — Case-sensitive is off, so `Apple` and `apple` are treated as equivalent for ordering and sort as neighbors. This is the natural choice for human-readable lists, where you rarely want all capitalized words to jump ahead of lowercase ones. Turn Case-sensitive on to get a strict ordering where uppercase letters sort before lowercase (following Unicode code-point order within the collator's variant sensitivity). Case sensitivity also affects deduplication when that option is enabled: with it off, `Foo` and `foo` count as the same line. **Q: Can I sort and remove duplicates at the same time?** A: Yes. Enable Remove duplicate lines alongside any sort order. The tool deduplicates first, then sorts, so you get a clean, unique, ordered list in a single step — and the stats badge reports how many duplicates were removed. This is the fastest way to turn a messy pasted column (say, a list of emails or tags with repeats) into a tidy sorted set. If you need the dedicated deduplication workflow with keep-first/keep-last control, use the companion Remove Duplicate Lines tool, which shares the same engine. **Q: What happens to blank lines when I sort?** A: By default, blank lines are kept and sort to the top (an empty string sorts before any non-empty line). If you don't want them, enable Remove empty lines to drop blank and whitespace-only lines before sorting — the stats badge counts how many were removed. A single trailing newline at the end of your input (common when pasting from files or editors) is treated as a line terminator, not an extra empty line, so it won't inflate your counts or add a spurious blank row to the output. **Q: How are accented and non-English characters sorted?** A: Sorting is locale-aware through the browser's `Intl.Collator`, which follows the Unicode Collation Algorithm. Accented letters are ordered the way a reader of your language expects — for example, in most Latin locales `é` sorts next to `e` rather than at the end of the alphabet. The tool uses the page's language for collation, so the German, French, Spanish, and other localized versions apply the appropriate rules. This is far more correct than a naive code-point sort, which would scatter accented and non-ASCII characters in surprising places. **Q: Is there a limit on how many lines I can sort?** A: There is no hard limit imposed by the tool — it is bounded only by your browser's memory and how much text you can comfortably paste into a textarea. Modern browsers sort tens of thousands of lines instantly and hundreds of thousands with a brief pause. Because everything runs locally with no network round-trips, large lists are often faster here than on server-based tools that upload your data. For truly massive files (millions of lines), a command-line `sort` utility will be more comfortable, but for everyday lists, wordlists, and exports this tool handles them with ease. **Q: How is this different from sorting in Excel or a code editor?** A: Spreadsheets sort cells within a grid and often reorder entire rows; this tool sorts a flat list of lines, which is exactly what you need for wordlists, config values, import statements, or any newline-separated data. Compared with a code editor's sort-lines command, this tool adds natural (numeric-aware) sorting, locale-aware collation, one-click deduplication, length sorting, and a live count — without installing an extension. And unlike online spreadsheet tools, nothing leaves your browser. It is the quickest way to sort a chunk of text when you just have it on the clipboard. **Q: What does the Shuffle option do?** A: Shuffle randomizes the order of your lines using a Fisher–Yates shuffle driven by the browser's cryptographic random number generator (`crypto.getRandomValues`), so the result is genuinely unpredictable and different each time. It is mutually exclusive with sorting — you either order the lines or randomize them. Common uses include randomizing quiz or flashcard order, choosing a fair draw sequence, sampling a subset, or de-biasing a list before manual review. Because it uses a cryptographic RNG rather than `Math.random`, it is suitable when you need defensible randomness. --- ### SQL Formatter & Beautifier URL: https://go-tools.org/tools/sql-formatter Format, beautify and minify SQL instantly in your browser. Supports PostgreSQL, MySQL, SQL Server, BigQuery, Snowflake, Oracle & SQLite. Free, private — your SQL never leaves your device. #### What is SQL Formatting? SQL formatting (also called beautifying or pretty-printing) rewrites a query with consistent indentation, line breaks and keyword casing so its structure is easy to read. The query runs identically before and after — only the whitespace changes. Formatting makes long queries reviewable in pull requests, easier to debug, and consistent across a team. Minifying does the reverse: it strips comments and collapses the query to a single compact line for embedding in code or logs. #### FAQ **Q: How do I format SQL online?** A: Paste your SQL into the input box, choose your database dialect, and click Format. The tool reindents the query with consistent line breaks and keyword casing, then lets you copy it. Everything runs locally in your browser — nothing is uploaded. **Q: How do I format PostgreSQL queries?** A: Select PostgreSQL from the dialect dropdown before clicking Format. This makes the formatter respect PostgreSQL-specific syntax such as dollar-quoted strings, casts (::), and functions, producing correct, idiomatic output. **Q: How do I format SQL Server (T-SQL)?** A: Choose "SQL Server (T-SQL)" as the dialect. The formatter then understands T-SQL constructs like bracketed [identifiers], TOP, and variables, so they are indented and cased correctly. **Q: How do I format Snowflake or BigQuery SQL?** A: Both are in the dialect dropdown. Selecting Snowflake or BigQuery applies their respective parsers so warehouse-specific functions and syntax format cleanly instead of being mangled by a generic SQL parser. **Q: Is my SQL safe with this tool?** A: Yes. All formatting and minifying happen locally in your browser using JavaScript — your queries are never sent to any server, logged, or stored. This makes it safe to use with production schemas and proprietary queries, unlike server-side formatters that receive a copy of everything you paste. **Q: What is the difference between formatting and minifying SQL?** A: Formatting (beautifying) adds indentation and line breaks to make a query readable. Minifying does the opposite: it removes comments and collapses the query to a single compact line, useful for embedding SQL in code or reducing log noise. Both produce queries that run identically to the original. **Q: Does this tool change what my query does?** A: No. Formatting and minifying only change whitespace, line breaks, comments and keyword casing — never the logic. The formatted query returns exactly the same results as the original. **Q: What indentation should I use for SQL?** A: Two spaces is the most common default and keeps diffs compact; four spaces improves readability for deeply nested queries; tabs let each developer view their preferred width. Pick one and apply it consistently across your team — this tool supports all three. --- ### IPv4 Subnet Calculator URL: https://go-tools.org/tools/subnet-calculator Free IPv4 subnet calculator: enter 192.168.1.130/26 for the network address, broadcast, usable host range, netmask and wildcard, plus paste-ready Cisco and Linux config. #### What Is a Subnet Mask? A subnet mask splits a 32-bit IPv4 address into two parts: a network portion that every host on the segment shares, and a host portion that identifies the individual machine. The mask is itself 32 bits — a run of 1s marking the network bits followed by 0s marking the host bits — which is why 255.255.255.0 and /24 describe exactly the same thing. CIDR notation just counts the 1 bits instead of spelling them out in decimal. Everything else follows from that split. Zero out the host bits and you have the network address; set them all to 1 and you have the directed broadcast address; the addresses between the two are what you can assign to hosts. That is where the familiar 2^n − 2 formula comes from, and also why a /26 yields 62 usable hosts rather than 64. When a machine decides whether a destination is local or needs a router, it applies its own mask to both addresses and compares the results — which is precisely the membership test this calculator performs. Two prefixes break the pattern on purpose. A /31 has only two addresses, leaving no room for a separate network and broadcast; RFC 3021 therefore makes both usable on point-to-point links, and every current router platform honours that. A /32 is a single host route, used for loopback interfaces, static routes, anycast addresses and single-address firewall rules. Applying 2^n − 2 blindly to either one yields 0 usable hosts — an answer no router platform agrees with. The /31 exception carries its own condition: it works only on genuinely point-to-point interfaces, so a shared LAN segment still needs /30 or shorter. The address you type also carries meaning beyond its mask. 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are private (RFC 1918) and never routed on the public internet; 100.64.0.0/10 is carrier-grade NAT space; 169.254.0.0/16 appears when DHCP fails; 224.0.0.0/4 is multicast. Historical classes A through E still surface in documentation and certification exams, but classful routing has been obsolete since CIDR arrived in 1993 — the mask, not the first octet, decides where a network ends. To inspect the same address in binary or hexadecimal by hand, the number base converter does the arithmetic. ``` // Subnetting is integer arithmetic on a 32-bit value. const toInt = (ip) => ip.split('.').reduce((acc, o) => acc * 256 + Number(o), 0); const toIp = (n) => [24, 16, 8, 0].map((s) => (n >>> s) & 255).join('.'); function subnet(ip, prefix) { const mask = prefix === 0 ? 0 : (0xFFFFFFFF << (32 - prefix)) >>> 0; const network = (toInt(ip) & mask) >>> 0; const broadcast = (network | (~mask >>> 0)) >>> 0; // RFC 3021: a /31 has two usable addresses; a /32 has one. const usable = prefix >= 31 ? 2 ** (32 - prefix) : 2 ** (32 - prefix) - 2; return { network: toIp(network), broadcast: toIp(broadcast), usable }; } subnet('192.168.1.130', 26); // { network: '192.168.1.128', broadcast: '192.168.1.191', usable: 62 } ``` #### FAQ **Q: How do I calculate a subnet mask from a CIDR prefix?** A: The prefix is simply the count of leading 1 bits in the 32-bit mask. A /26 means 26 ones followed by 6 zeros: 11111111.11111111.11111111.11000000, which reads back as 255.255.255.192. The trailing zeros are the host bits, so the block holds 2^6 = 64 addresses. Working the other way, count the 1 bits in the mask: 255.255.252.0 is 11111111.11111111.11111100.00000000 = 22 ones, so it is a /22. The binary view in this calculator shows the boundary directly, with network bits and host bits in different colours. **Q: What prefix length is 255.255.255.0?** A: It is a /24. 255 in binary is 11111111, so three octets of 255 give 24 leading 1 bits, and the last 8 bits are host bits — 255.255.255.0 = /24, with 256 addresses and 254 usable hosts. By the same reasoning 255.255.255.192 is a /26 (64 addresses, 62 usable), 255.255.252.0 is a /22 (1,024 addresses, 1,022 usable), and 255.255.255.128 is a /25 (128 addresses, 126 usable). Paste a dotted-decimal mask straight into the input to read its prefix back, or use the reference table below the calculator, which lists the mask, wildcard and host count for every prefix from /8 to /32. **Q: How do I convert an IP address to a decimal integer or hexadecimal?** A: Treat the four octets as one 32-bit integer: 192.168.1.128 = 192×256³ + 168×256² + 1×256 + 128 = 3232235904, which is 0xC0A80180 in hexadecimal. This form turns up when a database stores addresses in an integer column (MySQL's `INET_ATON` / `INET_NTOA`), when filtering logs by range, and in any bitwise membership test. The binary panel of this calculator prints the network address as a decimal integer, as hexadecimal, and as a reverse-DNS in-addr.arpa name. To convert between bases by hand, use the number base converter. **Q: How do I apply the result to a Cisco or Huawei device?** A: The ready-to-paste configuration panel generates six forms for the current block. For 192.168.1.130/26 those are: Cisco IOS interface `ip address 192.168.1.129 255.255.255.192`; Cisco ACL with the wildcard `access-list 10 permit 192.168.1.128 0.0.0.63`; OSPF `network 192.168.1.128 0.0.0.63 area 0`; Cisco ASA, which takes the subnet mask instead, `access-list OUT permit ip 192.168.1.128 255.255.255.192 any`; Huawei/H3C `ip address 192.168.1.129 26`; and Linux iproute2 `ip addr add 192.168.1.129/26 dev eth0`. **The trap is that IOS ACLs and OSPF take the wildcard while the ASA takes the subnet mask** — swapping them raises no error but matches a completely different range. **Q: Why is the usable host count two less than the total?** A: Every ordinary IPv4 subnet reserves its first address as the network identifier and its last as the directed broadcast address, so a /24 with 256 addresses offers 254 to hosts. Two prefixes are exceptions: a /31 has no room for those reserved addresses, and RFC 3021 makes both of its addresses usable on point-to-point links; a /32 is a single host route with one usable address. This calculator applies those exceptions — the generic 2^n − 2 formula would report 0 usable addresses for a /31, which no modern router agrees with. **Q: What is a wildcard mask and how is it different from a subnet mask?** A: A wildcard mask is the bitwise inverse of the subnet mask: where the subnet mask has 1s, the wildcard has 0s. For a /26, the mask is 255.255.255.192 and the wildcard is 0.0.0.63. Cisco access control lists and OSPF network statements take wildcards rather than masks, so `access-list 10 permit 192.168.1.128 0.0.0.63` matches the same block as 192.168.1.128/26. Huawei and H3C documentation calls it a wildcard mask too, while inverse mask is common shorthand among engineers; both names refer to the same value here. Note that ACL wildcards may legally have non-contiguous bits (matching odd or even addresses, for instance) while subnet masks may not. **Q: How many hosts fit in a /24, /25 or /26?** A: A /24 (255.255.255.0) has 256 addresses and 254 usable hosts. A /25 (255.255.255.128) has 128 addresses and 126 usable. A /26 (255.255.255.192) has 64 addresses and 62 usable. Each additional prefix bit halves both numbers. A useful shortcut when subnetting the fourth octet: the block size is 256 minus the last mask octet, so a mask ending in 192 steps every 64 addresses and a mask ending in 240 steps every 16. The full reference table under the calculator covers /8 through /32. **Q: Which IP ranges are private and which are public?** A: RFC 1918 reserves three private ranges: 10.0.0.0/8 (16,777,214 usable), 172.16.0.0/12 (1,048,574 usable) and 192.168.0.0/16 (65,534 usable). Note that the 172 range covers 172.16.0.0 to 172.31.255.255 only — 172.15.x.x and 172.32.x.x are public, a boundary that is easy to get wrong. Beyond those, 100.64.0.0/10 is carrier-grade NAT space (RFC 6598), 169.254.0.0/16 is link-local autoconfiguration (RFC 3927), and 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 are reserved for documentation (RFC 5737). This calculator labels whichever block your address falls into. **Q: Can I use a /31 or /32 on a real network?** A: Yes. A /31 is the standard way to number router-to-router links: RFC 3021 removes the network and broadcast addresses for point-to-point interfaces so both addresses go to the two endpoints, halving the waste compared with the traditional /30. It is supported on Cisco IOS, Junos, Arista EOS and Linux, but it is only valid on genuinely point-to-point interfaces — do not put a /31 on a multi-access LAN segment. A /32 is a host route: loopback interfaces, single-address ACL entries, static routes and anycast addresses all use it. **Q: Are the addresses I type sent to a server?** A: No. Every calculation runs locally in your browser with plain integer arithmetic — no network request, no third-party library, no logging. You can open your browser's developer tools and watch the network panel stay silent while you type, or disconnect from the internet entirely and keep calculating. The Copy link button encodes the current block into the URL fragment, which browsers never transmit to a server. --- ### Temperature Converter — Celsius, Fahrenheit, Kelvin, Rankine URL: https://go-tools.org/tools/temperature-converter Convert Celsius, Fahrenheit, Kelvin and Rankine instantly. Free online browser-based tool with conversion formulas, step-by-step guides and reference charts. #### What Is a Temperature Converter? A temperature converter is a tool that translates temperature measurements between different scales — most commonly Celsius (°C), Fahrenheit (°F), Kelvin (K), and Rankine (°R). Unlike length or mass conversions that apply a simple multiplication factor, temperature conversions require offset formulas because the scales have different zero points and, in some cases, different degree sizes. The four major temperature scales are: **Celsius (°C)** — used worldwide for everyday temperature measurement. Water freezes at 0 °C and boils at 100 °C at standard pressure. Developed by Anders Celsius in 1742. **Fahrenheit (°F)** — used primarily in the United States for weather, cooking, and medical contexts. Water freezes at 32 °F and boils at 212 °F. Developed by Daniel Gabriel Fahrenheit in 1724. **Kelvin (K)** — the SI unit of temperature, named after Lord Kelvin (William Thomson) and used in science and engineering. As defined by NIST and BIPM, it starts at absolute zero (0 K = −273.15 °C), the lowest theoretically possible temperature, where all atomic motion ceases. A change of 1 K equals a change of 1 °C — only the zero point differs. Because Kelvin begins at absolute zero, thermodynamic equations can multiply and divide temperatures directly without offset adjustments, making it indispensable in physics, chemistry, and engineering. **Rankine (°R)** — an absolute temperature scale based on Fahrenheit degrees. Used in some US engineering applications. 0 °R = absolute zero = −459.67 °F. All conversions in this tool use the exact mathematical formulas, running entirely in your browser with no server calls — your temperature values never leave your device. For a deeper dive, see our temperature conversion formula guide — 5 programming languages, weather API pitfalls, and reference tables. Need to convert other measurement types? Try our length converter for distance units, weight converter for mass units, or volume converter for liquid measurements. ``` // Temperature conversion formulas: // Celsius to Fahrenheit: °F = °C × 9/5 + 32 // Fahrenheit to Celsius: °C = (°F − 32) × 5/9 // Celsius to Kelvin: K = °C + 273.15 // Kelvin to Celsius: °C = K − 273.15 const celsiusToFahrenheit = (c) => c * 9/5 + 32; const fahrenheitToCelsius = (f) => (f - 32) * 5/9; const celsiusToKelvin = (c) => c + 273.15; const kelvinToCelsius = (k) => k - 273.15; console.log(celsiusToFahrenheit(100)); // 212 console.log(fahrenheitToCelsius(98.6)); // 37 console.log(celsiusToKelvin(0)); // 273.15 ``` #### FAQ **Q: What is the formula to convert Celsius to Fahrenheit?** A: The formula is °F = °C × 9/5 + 32. To convert Celsius to Fahrenheit, multiply the Celsius value by 9/5 (or 1.8), then add 32. For example, 25 °C = 25 × 1.8 + 32 = 77 °F. To convert back, use °C = (°F − 32) × 5/9. Common reference points: 0 °C = 32 °F (freezing), 100 °C = 212 °F (boiling), 37 °C = 98.6 °F (body temperature). **Q: What is the difference between Celsius and Kelvin?** A: Celsius and Kelvin use the same degree size — a 1-degree change in Celsius equals a 1-degree change in Kelvin. The only difference is the zero point: 0 K (absolute zero) equals −273.15 °C. To convert, use K = °C + 273.15 or °C = K − 273.15. Kelvin is the SI unit of temperature and is used in scientific contexts because it starts at absolute zero, making it ideal for thermodynamic calculations. **Q: What is absolute zero?** A: Absolute zero is the lowest possible temperature, defined as 0 K (Kelvin), which equals −273.15 °C or −459.67 °F. At absolute zero, atoms reach their lowest energy state and thermal motion effectively ceases. While absolute zero cannot be physically achieved, scientists have cooled matter to within billionths of a degree above it. It serves as the foundation for the Kelvin scale and is essential in thermodynamics, cryogenics, and quantum physics. **Q: What is the Rankine scale and when is it used?** A: The Rankine scale (°R) is an absolute temperature scale based on the Fahrenheit degree. Just as Kelvin uses Celsius-sized degrees starting from absolute zero, Rankine uses Fahrenheit-sized degrees starting from absolute zero (0 °R = −459.67 °F). It is primarily used in certain engineering fields in the United States, particularly in thermodynamic calculations involving the Fahrenheit system. To convert: °R = °F + 459.67 or °R = K × 9/5. **Q: At what temperature are Celsius and Fahrenheit equal?** A: Celsius and Fahrenheit are equal at −40 degrees. You can prove this algebraically: set °C = °F in the formula °F = °C × 9/5 + 32, which gives °C = °C × 9/5 + 32, solving to °C = −40. This is the only point where the two scales intersect, and it serves as a useful memory aid for understanding the relationship between the scales. **Q: Why does the United States use Fahrenheit instead of Celsius?** A: The United States inherited the Fahrenheit scale from the British system before the metric system gained global adoption. While most countries switched to Celsius during metrication in the 1960s–1970s, the US never completed the transition. Fahrenheit remains in everyday use for weather, cooking, and medical contexts. However, US scientists, engineers, and the military typically use Celsius or Kelvin. The Fahrenheit scale offers slightly finer granularity for ambient temperatures (180 degrees between freezing and boiling vs. 100 in Celsius). **Q: How accurate is this temperature converter?** A: This converter uses the exact mathematical formulas for temperature conversion with IEEE 754 double-precision floating-point arithmetic, providing at least 15 significant digits of precision. The conversion formulas are exact — there are no approximations in the mathematical relationships between Celsius, Fahrenheit, Kelvin, and Rankine. The only limitation is inherent floating-point rounding at extreme precision levels. **Q: Is my data safe when using this temperature converter?** A: Yes, completely. All conversions are performed locally in your browser using JavaScript. No data is sent to any server — there are no network requests, no cookies, and no analytics on your input. The conversion logic runs entirely on your device, meaning your values never leave your browser. You can verify this by disconnecting from the internet and using the tool — it works fully offline once the page has loaded. **Q: What is the easiest way to convert Celsius to Fahrenheit in your head?** A: The simplest mental trick for Celsius to Fahrenheit: double the Celsius value and add 30. For example, 20 °C → 20 × 2 + 30 = 70 °F (actual: 68 °F). For Fahrenheit to Celsius: subtract 30 and divide by 2. These shortcuts are accurate within ±2–3 degrees for everyday temperatures (0–40 °C), which is close enough for weather and travel. **Q: What temperature is 350 °F in Celsius?** A: 350 °F equals approximately 176.67 °C. In practice, this is rounded to 175 °C or 180 °C depending on the recipe. This is the most common oven temperature in American baking, used for cookies, cakes, casseroles, and roasted vegetables. European recipes typically list this as 180 °C. **Q: Why do scientists use Kelvin instead of Celsius?** A: Scientists prefer Kelvin because it is an absolute scale starting at absolute zero (0 K), where all thermal motion ceases. This makes thermodynamic equations simpler — you can directly multiply, divide, and compare temperatures without negative numbers or offset adjustments. The Kelvin is also the SI base unit of temperature, ensuring consistency across international scientific communication. **Q: Can temperatures go below absolute zero?** A: In classical thermodynamics, absolute zero (0 K) is the lower limit. However, in quantum physics, researchers have created systems with 'negative absolute temperatures' — but this does not mean colder than absolute zero. Negative temperatures describe inverted energy distributions where most particles occupy high-energy states. These systems are actually hotter than any positive temperature, as energy flows from them to any positive-temperature system. **Q: I need to convert my oven temperature from Fahrenheit to Celsius for a European recipe — how do I do it?** A: Use the formula °C = (°F - 32) × 5/9, or simply enter the Fahrenheit value in this tool and select Fahrenheit-to-Celsius. Common oven conversions: 325 °F = 163 °C, 350 °F = 177 °C (use 175 or 180 °C), 375 °F = 191 °C (use 190 °C), 400 °F = 204 °C (use 200 °C), 425 °F = 218 °C (use 220 °C), 450 °F = 232 °C (use 230 °C). European ovens typically have markings in 10 °C increments, so round to the nearest 5 or 10 °C. Most recipes are forgiving of ±5 °C differences. **Q: I need to check if my child has a fever — is 99.5 °F considered a fever in Celsius?** A: 99.5 °F equals 37.5 °C. This is slightly above the commonly cited normal body temperature of 37 °C (98.6 °F), but whether it constitutes a fever depends on context. Most medical guidelines define a fever as an oral temperature of 100.4 °F (38 °C) or higher. A reading of 37.5 °C is considered a low-grade or borderline temperature. For children, always consult your pediatrician's guidelines. You can use this tool to quickly convert any temperature reading between Fahrenheit and Celsius for medical reference. --- ### Text Diff & Compare URL: https://go-tools.org/tools/text-diff Compare two texts instantly in your browser. Side-by-side view with inline word-level highlights, unified-diff export, ignore case / whitespace / blank lines. 100% private — your text never leaves your device. #### What is text diff? Text diff is a structured comparison of two text documents that finds the smallest set of insertions and deletions transforming one into the other. The output makes the change visible: green for added lines, red for removed, side-by-side or in unified-patch form (the `---/+++/@@` format used by `git`, GitHub, and the Unix `patch` command). Under the hood every modern diff is a Longest Common Subsequence (LCS) algorithm. Eugene Myers' 1986 O((N+M)D) paper is the canonical efficient implementation; classical dynamic programming (used here, with common prefix/suffix trimming) is simpler and works perfectly for typical web inputs. After lines line up, neighbouring remove + add pairs are run through a second token-level LCS so the renderer can highlight only the words that actually changed inside a line — what reviewers call intra-line or word-level diff. Why not just compare strings character-by-character? Because edits are rarely flat: inserting one line in the middle of a 200-line file shifts every line below it. A naïve `===` would call all 199 lines different. LCS tells you the truth: one line added, 199 unchanged. This tool runs the entire comparison in your browser. No upload, no temporary file, no log. Safe for proprietary code, redlined contracts, private logs, anything you'd be uncomfortable pasting into a third-party server. Need to diff JSON instead? Use the structural JSON Diff so key order and whitespace stop being noise. Comparing two configs in YAML or CSV? Convert with YAML to JSON or JSON to CSV first, then diff with the right tool for the format. ``` // Two strings that look 'mostly the same' but a naïve check disagrees const a = 'hello world'; const b = 'hello, world!'; // Character equality a === b; // false — but only 3 characters actually changed. // LCS-style diff (this tool, at line + word granularity) // → 1 line modified, inline highlight: 'hello[, ]world[!]' // → unified patch: // --- original // +++ modified // @@ -1 +1 @@ // -hello world // +hello, world! ``` #### FAQ **Q: Is the text I paste sent to your server?** A: No. Every comparison runs in JavaScript inside your browser. Your text is not uploaded, logged, stored on disk, or sent to any third party. Only your UI preferences (view mode and ignore-option toggles) are saved to localStorage so the page remembers them next visit — never the text. You can verify this by opening DevTools → Network: zero requests fire when you click Diff. **Q: What's the difference between text diff and JSON diff?** A: Text diff compares line by line — perfect for prose, code, logs, contracts, config files. JSON Diff understands JSON's data model: key order is irrelevant, types are strict, arrays can be matched by key. If you paste JSON into a text diff, key reorders and whitespace differences will be flagged as changes; JSON Diff ignores them. Use text diff for unstructured content, JSON Diff for API responses and config payloads. **Q: How do I ignore whitespace, case, or blank lines?** A: Click the 'Ignore options' panel above the diff. 'Ignore case' makes A and a equal. 'Ignore all whitespace' collapses every space, tab, and newline before comparison. 'Ignore trailing spaces / tabs' only strips end-of-line whitespace — the standard `git diff -b` behavior. 'Ignore blank lines' drops empty/whitespace-only lines before diffing. Each option is independent and persists across visits. **Q: What's a unified diff (and when do I copy it)?** A: A unified diff is the `---/+++/@@` text format used by `patch`, `git apply`, GitHub PRs, and most code-review tools. Click Copy unified diff to grab a patch with three lines of context around every change — paste it into a bug report, a code-review comment, or a `patch -p1` command and it applies cleanly. Side-by-side is for humans, unified diff is for machines (and code reviewers who think like machines). **Q: Why does the diff show whole lines changed when I only edited one word?** A: It doesn't — look closer. The full line is highlighted because something on it changed, but inside the highlight only the changed tokens carry the bright background (green for added, red strikethrough for removed). This is intra-line word diff: the line context stays readable while your eye lands on the exact edit. If two consecutive lines were both modified, both show inline highlighting. **Q: How are CRLF vs LF line endings handled?** A: Both are recognized. The diff splits on \r\n, \n, and bare \r, so Windows CRLF, Unix LF, and old-Mac CR text all line up correctly. If you want to flag line-ending changes specifically, leave 'Ignore trailing spaces / tabs' off — \r will surface as a trailing character. To erase line-ending noise entirely, turn 'Ignore all whitespace' on. **Q: How large can the two inputs be?** A: The diff runs on the main thread, so practical limits are about 5,000 lines or 1 MB per side; above that we clip and show a warning. Live diff disables above 200 KB combined and switches to a manual Diff button. For multi-megabyte files, use command-line `diff -u` or `git diff --no-index` — they stream and handle gigabytes. **Q: What about diffing code? Does it know my language?** A: The diff is language-agnostic: it sees lines and tokens, not syntax. That's a feature for review snippets, config edits, and copy-pasted patches. If you want semantic code diff (renamed function across files, AST-level), use git, GitHub PR view, or a dedicated structural diff tool. For 90% of code-review situations — eyeballing a function, comparing two snippets — line + word diff is what you want. **Q: Why does a single edit sometimes appear as a removed line plus an added line?** A: When too much of a line changed for word-level highlighting to be useful, the diff reports it as separate remove + add lines so the structure stays clean. The same heuristic gives readable output for prose rewrites and for code blocks that were rewritten rather than edited. Switch to Unified view to see the classic `-`/`+` pair format used in patches. **Q: How is the % match similarity calculated?** A: It's the number of unchanged lines (after applying ignore options) divided by the larger of the two line counts, clamped to 100%. Two identical inputs are 100%. Adding one new line to a 100-line file gives 99%. Replacing every line is 0%. Useful for quickly judging 'is this a small edit or a wholesale rewrite' before reading the diff. **Q: Can I share a diff with a colleague?** A: Yes, two ways. (1) Click Copy unified diff and paste the patch into chat, Slack, or a PR comment — anyone with a terminal can `patch < clip` it. (2) Take a screenshot of the side-by-side panel for visual review. We deliberately do not provide a 'share by URL' button: that would require uploading your text, which we don't do. **Q: Does the diff handle right-to-left languages like Arabic or Hebrew?** A: Yes for the text content — lines and tokens are Unicode-aware. The interface uses logical CSS directions, so on RTL locales the gutter and line columns flip naturally. Inside a diff cell the text direction follows the content, so Arabic and Hebrew strings render correctly while the +/- markers stay aligned to the gutter. --- ### TOML to JSON Converter URL: https://go-tools.org/tools/toml-to-json Paste TOML, get JSON instantly in your browser. Cargo.toml, pyproject.toml & config.toml ready. Dates and nested tables handled right. 100% private, no upload. #### What is TOML and Why Convert to JSON? TOML (Tom's Obvious, Minimal Language) is a configuration file format created by Tom Preston-Werner to be unambiguous, easy for humans to read, and trivially mappable to a hash table. It has become the default configuration format for the Rust ecosystem (Cargo.toml), modern Python packaging (pyproject.toml, standardized in PEP 518 and PEP 621), and tools like Hugo, Netlify, Poetry, and Foundry. JSON, by contrast, is the universal machine-interchange format — every language parses it, every API speaks it. Converting TOML to JSON is therefore a common task: you author configuration in readable TOML, then convert to JSON to feed a program, inspect it with JSON tooling, or diff it in a pipeline. This tool has several differentiators that matter for correctness: **1. Date-time fidelity.** TOML has first-class date and time types — offset date-time, local date-time, local date, and local time — that JSON lacks entirely. Naive converters flatten all of them into ISO timestamps, so a local date like 1979-05-27 becomes 1979-05-27T00:00:00Z, silently inventing a time and a timezone. This tool preserves the exact TOML kind: local dates stay calendar dates, local times stay times, and only offset date-times carry a timezone. That keeps your data honest and round-trips lossless. **2. Full TOML 1.0.0 support.** Nested tables, dotted keys, inline tables, and arrays of tables ([[section]]) are all parsed correctly according to the TOML 1.0.0 specification using the zero-dependency smol-toml library. Real Cargo.toml and pyproject.toml files with mixed inline and standard tables convert exactly as the spec requires. **3. Honest large-integer handling.** TOML integers are 64-bit, but browser JavaScript can only hold integers up to 2^53 - 1 exactly. Rather than silently corrupting a large value or crashing, this tool converts to the nearest JSON number and warns you, so you can choose to store the value as a string instead. This honesty about a fundamental browser limitation is something most converters gloss over. **4. 100% browser-based privacy.** Your TOML — which may contain registry tokens, internal package sources, or deployment secrets — never leaves your browser. No upload, no server, no logging. You can confirm this in your browser's Network tab. Need the reverse? Use the JSON to TOML Converter. Converting between other config formats? Try the JSON to YAML Converter and YAML to JSON Converter, or validate and pretty-print your JSON output first with the JSON Formatter. TOML, JSON, and YAML each have their place: TOML for human-edited application config, JSON for machine interchange, and YAML for deeply nested infrastructure manifests. This converter lets you move between the first two without a single line of code. ``` // Convert TOML to JSON in Node.js using the smol-toml library import { parse } from 'smol-toml'; const toml = ` [package] name = "my-app" version = "1.0.0" [dependencies] serde = { version = "1.0", features = ["derive"] } `; const data = parse(toml); const json = JSON.stringify(data, null, 2); console.log(json); // { // "package": { "name": "my-app", "version": "1.0.0" }, // "dependencies": { // "serde": { "version": "1.0", "features": ["derive"] } // } // } ``` #### FAQ **Q: How do I convert TOML to JSON online?** A: Paste your TOML into the input field above. The tool parses it and produces JSON instantly in your browser — no button click needed. You can switch the JSON indentation between 2 and 4 spaces in the Options panel. Once the JSON appears in the output area, click Copy to grab it to your clipboard or Download to save it as a .json file. Everything runs locally, so your TOML never leaves your device. **Q: What is TOML and why convert it to JSON?** A: TOML (Tom's Obvious, Minimal Language) is a configuration file format designed to be easy for humans to read and write, with clear semantics that map unambiguously to a hash table. It powers Rust's Cargo.toml, Python's pyproject.toml, Hugo, Netlify, and many other tools. You convert TOML to JSON when you need to feed configuration into a program or API that expects JSON, inspect a config file programmatically, diff two configs with JSON tooling, or drive a UI. TOML is written by humans; JSON is consumed by machines — this converter bridges the two. **Q: How are TOML dates and times represented in JSON?** A: JSON has no native date type, so TOML date-times are converted to strings. This tool preserves the exact TOML date kind: an offset date-time like 1979-05-27T07:32:00Z becomes "1979-05-27T07:32:00.000Z", a local date like 1979-05-27 stays "1979-05-27" (it is not padded into a full timestamp), and a local time like 07:32:00 becomes "07:32:00.000". Many converters incorrectly flatten local dates into midnight UTC timestamps — this one keeps the original meaning so round-trips are lossless. **Q: Does this tool handle Cargo.toml and pyproject.toml?** A: Yes. Cargo.toml and pyproject.toml are the two most common real-world TOML files, and both are fully supported, including nested tables ([dependencies], [tool.ruff]), inline tables (serde = { version = "1.0", features = ["derive"] }), and arrays of tables ([[bin]]). Load the Cargo.toml or pyproject.toml example above to see the exact JSON structure produced. This is handy for build dashboards, dependency audits, or any script that reads project metadata as JSON. **Q: How are TOML tables and arrays of tables converted?** A: A TOML table header like [owner] becomes a nested JSON object under the key "owner". A dotted table like [tool.ruff] becomes nested objects: { "tool": { "ruff": { ... } } }. An array of tables written with double brackets — [[servers]] repeated — becomes a JSON array of objects: { "servers": [ { ... }, { ... } ] }. Inline tables ({ a = 1, b = 2 }) become plain JSON objects. The conversion follows the TOML 1.0.0 specification exactly. **Q: What happens to very large integers when converting TOML to JSON?** A: TOML supports 64-bit signed integers, but JavaScript (and therefore JSON in the browser) can only represent integers exactly up to 2^53 - 1 (9007199254740991). If your TOML contains an integer larger than that — for example a Snowflake ID or a nanosecond timestamp — it cannot be represented losslessly as a JSON number, and the value is rounded, with a warning shown. This is a fundamental limitation of browser JavaScript that affects every browser-based converter. For exact preservation, keep such values as quoted strings in your TOML. **Q: Is my TOML data sent to any server?** A: No. All parsing and conversion happen entirely in your browser using JavaScript. Your TOML is never uploaded, never stored, and never logged. This makes the tool safe for Cargo.toml files with private registry tokens, pyproject.toml with internal package indexes, deployment configs with secrets, and any other sensitive configuration. You can verify this by opening your browser's Network tab — pasting TOML triggers zero network requests. **Q: Can I convert JSON back to TOML?** A: Yes. Use the companion JSON to TOML Converter for the reverse direction, or click the Swap direction button at the top of this tool to flip the input and output in place. Note that JSON to TOML has a few constraints TOML to JSON does not — the top level must be an object, and null values have no TOML equivalent — which the JSON to TOML tool explains and handles for you. **Q: How do I convert TOML to JSON on the command line?** A: A popular option is the Rust-based CLI 'toml' or the Go tool 'yj' (yj -tj reads TOML and writes JSON). With Python 3.11+ you can run: python3 -c "import tomllib, json, sys; print(json.dumps(tomllib.load(sys.stdin.buffer)))" < config.toml. With Node.js: npx smol-toml (or a small script using the smol-toml library). For a quick one-off in the browser without installing anything, this tool is the fastest path. **Q: How do I convert TOML to JSON in Python, Rust, or Node.js?** A: In Python 3.11+: import tomllib, json; data = tomllib.load(open('config.toml','rb')); json.dump(data, open('config.json','w')). In Rust: use the toml and serde_json crates — let value: toml::Value = toml::from_str(&text)?; let json = serde_json::to_string_pretty(&value)?. In Node.js: import { parse } from 'smol-toml'; const data = parse(text); const json = JSON.stringify(data, null, 2) — this is the same library and approach used by this tool. **Q: Does the converter preserve key order, and what about comments?** A: Key order within a table is preserved: keys appear in the JSON output in the same order they appear in your TOML. Comments, however, are dropped — JSON has no comment syntax, so TOML # comments cannot survive the conversion. If you need to keep documentation, add it as a JSON-friendly field or keep the original TOML alongside the generated JSON. **Q: Is there a file size limit for TOML input?** A: There is no hard limit, but inputs over 200KB switch from live conversion to manual mode: a Convert button appears and conversion runs only when you click it, keeping the browser responsive. Typical config files — even large Cargo.toml workspaces or multi-environment deployment configs — convert in well under 50 milliseconds. --- ### TOTP / 2FA Code Generator URL: https://go-tools.org/tools/totp-generator Generate a TOTP/2FA code from a Base32 secret instantly — 100% in your browser, your secret never leaves your device. QR setup + code verify. Free, no signup. #### What Is a TOTP / 2FA Code Generator? A TOTP generator turns a shared secret into the rotating one-time code that powers two-factor authentication. TOTP — Time-based One-Time Password, defined in RFC 6238 — takes a Base32 secret and the current time, splits time into fixed steps (30 seconds by default), and runs an HMAC over the step counter to derive a short numeric code. Because both your authenticator app and the server hold the same secret and read the same clock, they compute the identical code without ever exchanging it over the network. That is the whole point of 2FA: even if your password leaks, an attacker still needs the code that only your secret can produce right now. "The TOTP algorithm is a time-based variant of the HOTP algorithm... TOTP = HOTP(K, T), where T is an integer representing the number of time steps between the initial counter time T0 and the current Unix time." — RFC 6238, Section 4 This tool does three jobs on one page. It generates a live code from any Base32 secret with a countdown and next-code preview; it sets up a brand-new secret, building theotpauth://URI and QR code you scan into an authenticator app; and it verifies a code against a secret with a ±1 time-step tolerance, matching how real servers accept a code that just rotated. All of it runs through the browser's native Web Crypto API with zero dependencies and zero network calls. Developers reach for a TOTP generator constantly: to reproduce the exact code a user's app shows while debugging a 2FA login, to mint a secret and QR for a new account, to confirm that a verification window on the server matches what users experience, or to build deterministic fixtures for end-to-end tests of a two-factor flow. Because the secret is a long-lived key — anyone who has it can generate every future code — it must be protected like a password. Pair this tool with our random password generator for the strong passwords and recovery codes that sit alongside 2FA, and with the QR code generator when you need a standalone enrollment image. For signing the JSON Web Tokens that often ride on top of an authenticated session, see the JWT encoder. ``` // Generate a TOTP code in the browser with the Web Crypto API // (SHA-1, 6 digits, 30s period — RFC 6238 defaults) async function generateTotp(base32Secret, time = Date.now()) { // Decode the Base32 secret to raw bytes (A-Z, 2-7) const alpha = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567'; let bits = ''; for (const c of base32Secret.replace(/=+$/, '').toUpperCase()) bits += alpha.indexOf(c).toString(2).padStart(5, '0'); const bytes = new Uint8Array( bits.match(/.{8}/g).map((b) => parseInt(b, 2))); // Counter = number of 30s steps since the Unix epoch (8-byte big-endian) const counter = Math.floor(time / 1000 / 30); const msg = new Uint8Array(8); let c = counter; for (let i = 7; i >= 0; i--) { msg[i] = c & 0xff; c = Math.floor(c / 256); } const key = await crypto.subtle.importKey( 'raw', bytes, { name: 'HMAC', hash: 'SHA-1' }, false, ['sign']); const hmac = new Uint8Array(await crypto.subtle.sign('HMAC', key, msg)); // Dynamic truncation (RFC 4226) -> 6-digit code const off = hmac[hmac.length - 1] & 0x0f; const bin = ((hmac[off] & 0x7f) << 24) | (hmac[off + 1] << 16) | (hmac[off + 2] << 8) | hmac[off + 3]; return (bin % 1_000_000).toString().padStart(6, '0'); } const code = await generateTotp('JBSWY3DPEHPK3PXP'); // -> a 6-digit code that rotates every 30 seconds ``` #### FAQ **Q: Is an online TOTP / 2FA generator safe to use?** A: With this one, yes — and the reason is that nothing ever leaves your browser. The Base32 secret you type, theotpauth://URI, and the generated code are all computed locally with the native Web Crypto API. There are no network requests, no logging, no storage, and no analytics tied to your input — you can verify this by disconnecting from the internet and watching the tool keep working. That is the opposite of a sketchy generator that POSTs your secret to a server, where the operator could mint your codes forever. A TOTP secret is a long-lived shared key, so the safest habit is still to prefer disposable or test secrets when you just need to experiment. **Q: What is TOTP and what is a Base32 secret?** A: TOTP (Time-based One-Time Password, defined in RFC 6238) is the algorithm behind the rotating 6-digit codes in authenticator apps. It combines a shared secret with the current time, divided into fixed steps (usually 30 seconds), through an HMAC to produce a short code that both your device and the server can compute independently. The secret is the shared key, and it is almost always written in Base32 — uppercase letters A–Z and digits 2–7 — because that alphabet is case-insensitive and easy to type or encode in a QR code. The stringJBSWY3DPEHPK3PXPis the well-known RFC test secret. **Q: Why is the generated code different from my phone's authenticator app?** A: Four things have to match for two TOTP codes to agree. First, the clock: TOTP depends on the current time, so if your computer or phone clock is off by more than a step, the codes diverge — sync your system clock and try again. Second, the algorithm: this tool defaults to SHA-1 (what most apps use), but if your secret was issued for SHA-256 or SHA-512 you must select it here too. Third, the digits and period: 6 vs 8 digits, or a 30s vs 60s window, produce entirely different codes. Fourth, the secret itself — a single mistyped Base32 character changes every code. Line up all four and the codes will match. **Q: What's the difference between TOTP and HOTP?** A: Both come from the same HMAC-based one-time-password family, but they differ in what drives the code. HOTP (RFC 4226) is counter-based: each code is tied to an incrementing counter, so a code stays valid until it is used and the counter advances. TOTP (RFC 6238) is time-based: it replaces the counter with the current time divided into fixed steps, so codes rotate automatically every 30 seconds. TOTP is really just HOTP with the counter set to the number of time steps since the Unix epoch. This tool generates TOTP, which is what Google Authenticator, Authy, and 1Password use by default. **Q: Can I use 8-digit codes or SHA-256 / SHA-512?** A: Yes. Open the advanced options to switch the algorithm to SHA-256 or SHA-512, set digits to 8, or change the period to 60 seconds. These knobs exist because some enterprise and banking systems require longer codes or stronger hashes. That said, the overwhelming majority of services — and every mainstream consumer authenticator app — use the defaults of SHA-1, 6 digits, and a 30-second period, so leave them as-is unless your provider's setup instructions say otherwise. Whatever you choose, theotpauth://URI the tool generates records those parameters so your app enrolls the secret correctly. **Q: How do I add this secret to Google Authenticator, Authy, or 1Password?** A: Switch to the Set up tab to generate (or paste) a secret, then either scan the QR code or copy theotpauth://URI. In Google Authenticator or Authy, tap the add button and choose Scan a QR code to point your camera at the on-screen QR, or choose Enter a setup key and paste the Base32 secret with the matching account name and algorithm. In 1Password, edit a login item, add a One-Time Password field, and paste theotpauth://URI directly. Need a standalone QR image for documentation? Use our QR code generator, and for the random secrets and recovery codes around it, the random password generator. --- ### traceparent Decoder — W3C Trace Context URL: https://go-tools.org/tools/traceparent-decoder Stop counting hex digits. Free online traceparent decoder — runs in your browser, nothing uploaded. Trace ID, span ID, all 8 trace-flags bits, tracestate check, Datadog/X-Ray/B3 conversion. #### What Is the traceparent Header? traceparent is the HTTP header that carries a distributed trace from one service to the next. Before it was standardised, every tracing vendor propagated context in its own header, so a request that crossed systems lost its identity at the boundary. The W3C Trace Context specification fixed that with a single, deliberately small format:version-trace-id-parent-id-trace-flags, four hexadecimal fields joined by dashes, 55 characters in total for the current version. Each field does one job. The version is always 00 today, and ff is forbidden outright. The trace-id is 16 bytes identifying the whole request end to end — it stays constant across every hop. The parent-id is 8 bytes identifying the immediate caller's span, so unlike the trace-id it changes at every hop. The trace-flags byte is where most confusion lives: it looks like a boolean because 01 is by far the most common value, but it is eight bits. Bit 0 issampled. Bit 1, added in Trace Context Level 2, israndom-trace-id, asserting that the right-most seven bytes of the trace ID are uniformly random so that downstream systems may sample or shard on them. The remaining six bits are reserved, which is precisely why the field must be read with a bitwise AND rather than compared for equality. A companion header,tracestate, carries vendor-specific key-value pairs alongside it, capped at 32 members. That ceiling explains a puzzling symptom: vendor data that is present at the edge and gone several hops later, because intermediaries began dropping entries once the list grew past the limit. The header became genuinely universal once OpenTelemetry adopted it, and this page decodes all of it — fields, bits, tracestate members and the equivalent identifiers for other propagation formats — without sending anything anywhere. ``` # The header as it travels on the wire traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01 tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE # Read the four fields apart # version 00 # trace-id 4bf92f3577b34da6a3ce929d0e0e4736 (16 bytes, whole request) # parent-id 00f067aa0ba902b7 (8 bytes, calling span) # trace-flags 01 (bit 0 set = sampled) # Send one yourself $ curl -H 'traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01' \ https://example.com/api ``` #### FAQ **Q: What is the traceparent header?** A: It is the single HTTP header that carries a distributed trace across service boundaries, standardised by the W3C so that tools from different vendors can follow the same request. It holds four dash-separated fields — version, trace-id, parent-id and trace-flags — and for the current version it is always exactly 55 characters. Every major tracing system now speaks it, which is what makes a request traceable from an edge proxy through half a dozen services without every hop agreeing on a vendor. The full grammar is defined in the W3C Trace Context recommendation. **Q: What does traceparent trace-flags 00 mean?** A: It means the caller explicitly decided this trace should not be recorded. The sampled bit is bit 0 of the trace-flags byte; when it is clear, an upstream sampler evaluated the request and chose against recording it. This is the single most misread value in the header, because it looks like a failure and is in fact a decision. If spans are missing, the useful question is not what is broken in your service but which upstream service is sending you a parent span with sampling turned off — a parent-based sampler will then propagate that choice to everything downstream. **Q: What is the difference between trace-flags 01, 02 and 03?** A: trace-flags is an eight-bit field, so these values are combinations rather than an enumeration. 01 sets bit 0 only: the trace is sampled. 02 sets bit 1 only: the Level 2 random-trace-id flag, which asserts that at least the right-most seven bytes of the trace ID were generated with uniform randomness — downstream systems can then sample or shard on those bytes safely. 03 sets both. Because it is a bit field, you must test it with a bitwise AND; comparing the whole byte against 01 will misreport any trace that also carries a reserved bit, and reserved bits are exactly what future versions will start using. **Q: Why is my trace ID all zeros?** A: Because tracing was never initialised, not because the trace exists but has no data. The specification lists an all-zero trace-id as an invalid value and instructs receivers to ignore the entire header, so nothing downstream will link to it. In practice it comes from an SDK that failed to start, a manually constructed header, or middleware inserting a placeholder when no real context was available. The all-zero parent-id, 0000000000000000, is invalid for the same reason. **Q: How do I convert a W3C trace ID to a Datadog trace ID?** A: Take the lower 64 bits — the right-hand 16 hex digits — and render them as a decimal string; that is what goes in x-datadog-trace-id. The higher 64 bits stay hexadecimal and travel separately in the _dd.p.tid tag. The parent-id converts to decimal whole. Getting this backwards, or converting all 128 bits to one decimal number, produces an identifier that matches nothing in the UI, which is why it recurs across tracer issue trackers. This page performs the split for you; if you want to explore the underlying hexadecimal arithmetic on arbitrary values, the number base converter handles general base conversion, while this page stays specific to trace identifiers. **Q: Does a traceparent contain a timestamp?** A: No — and this trips people up because some other trace identifiers do. A W3C trace-id is 16 opaque bytes with no embedded time. An AWS X-Ray trace ID, by contrast, is 1-{8 hex}-{24 hex} where the first eight hex digits are the creation time in epoch seconds, so converting between the two formats moves the bytes around but cannot invent a timestamp that was never there. If you need identifiers that do sort by time, that is what UUIDv7 and ULID are for. **Q: Is the header I paste here uploaded anywhere?** A: No. Every field is parsed locally in your browser with plain string and BigInt arithmetic — there is no server call, no logging of what you type, and nothing retained. This matters more here than for most tools, because a traceparent taken from a production request identifies real traffic in your observability backend. You do not have to take our word for it: open your browser's developer tools, watch the Network panel stay silent while you type, or disconnect from the network entirely and keep decoding. The absence of any external request is also enforced by an automated contract test that runs on every build, so it cannot quietly regress. **Q: Does this decoder work offline?** A: Yes. The page is static and the decoder is a few kilobytes of JavaScript with no dependencies, so once it has loaded you can go offline — or turn on airplane mode before you paste anything — and it keeps working exactly the same. If you are handling headers from a sensitive environment, that is the sequence worth using: load the page, disconnect, then paste. The Copy link button encodes state in the URL fragment after the # character, and fragments are never transmitted to a server either. --- ### Free ULID Generator — Generate, Decode & Convert ULIDs URL: https://go-tools.org/tools/ulid-generator Generate, decode, and convert ULIDs online — free and 100% in your browser. Extract the embedded timestamp from any ULID, convert ULID to UUID and back, batch-generate, with a monotonic mode. Nothing is ever sent to a server. #### What is a ULID and why use one? A ULID — Universally Unique Lexicographically Sortable Identifier — is a 128-bit identifier created to fix a practical weakness of the random UUIDv4 while keeping its best property: you can generate one anywhere, with no central coordinator, and be confident it is unique. The difference is that a ULID is sortable by time. It is rendered as 26 characters of Crockford's Base32, split into two parts: the first 10 characters are a 48-bit timestamp counting milliseconds since the Unix epoch, and the last 16 characters are 80 bits of cryptographically secure randomness. Put the time first, encode it in an order-preserving alphabet, and the identifier sorts chronologically as a plain string. That single design choice has outsized consequences for databases. A random UUIDv4 primary key lands in an unpredictable spot in a B-tree index on every insert, which fragments the index, thrashes the cache, and slowly degrades write performance as a table grows. A ULID, because it is time-prefixed, lands at or near the end of the index every time — inserts stay sequential, the index stays compact, and range scans over a time window become cheap. You get the coordination-free generation of a UUID and the insert locality of an auto-incrementing integer, without exposing a guessable sequential counter. The encoding details are deliberate. Crockford's Base32 excludes the letters I, L, O, and U, both to avoid visual confusion with the digits 1 and 0 and to make the string case-insensitive on input. The result is 26 characters with no hyphens that are safe to drop into a URL, a filename, or a request header without escaping — noticeably shorter than a UUID's 36-character hyphenated form. The 48-bit timestamp does not run out for a long time: it can represent dates through the year 10889 before the millisecond counter overflows. ULIDs are not the right tool for everything. The embedded timestamp reveals when a record was created, which is a feature for debugging and ordering but a small information leak if you would rather not expose that. And if your stack is committed to the UUID type, you may prefer UUIDv7, which applies the same time-prefixed idea inside the standard UUID format. But when you want short, URL-safe, sortable identifiers that you can mint on any node and read a timestamp back out of, a ULID is an excellent default — and because it is just 128 bits, you can always convert it to and from a UUID with this tool's Convert tab. ``` // Browser / Node with the `ulid` package import { ulid, decodeTime } from 'ulid'; const id = ulid(); // e.g. 01KVT0F720ZK9N4T2QX7VR8WMC const ts = decodeTime(id); // 1782210600000 -> 2026-06-23T10:30:00.000Z // Monotonic factory: strictly increasing within the same millisecond import { monotonicFactory } from 'ulid'; const next = monotonicFactory(); next(1782210600000); // 01KVT0F720ZK9N4T2QX7VR8WMC next(1782210600000); // 01KVT0F720ZK9N4T2QX7VR8WMD next(1782210600000); // 01KVT0F720ZK9N4T2QX7VR8WME ``` #### FAQ **Q: What is a ULID?** A: A ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit identifier designed as a more sortable, more compact alternative to a UUID. It is written as 26 characters of Crockford's Base32: the first 10 characters hold a 48-bit timestamp in milliseconds since the Unix epoch, and the remaining 16 characters hold 80 bits of randomness. Because the timestamp is the most significant part and Base32 preserves order, ULIDs created later always sort after earlier ones when compared as plain strings — so a column of ULIDs is naturally time-ordered. The Crockford alphabet deliberately excludes the letters I, L, O, and U to avoid confusion with digits and to keep the string case-insensitive and URL-safe. ULIDs were introduced to solve a practical problem with random UUIDv4: random identifiers scatter across a database index, hurting insert performance, whereas a time-prefixed ULID lands near the end of the index every time. **Q: ULID vs UUID — which should I use?** A: Use a ULID when you want identifiers that are both unique and naturally sortable by creation time; use a classic UUIDv4 when you specifically need an opaque, fully random identifier with no embedded timestamp. The key differences: a ULID is 26 characters of Base32 versus a UUID's 36 characters with hyphens, so ULIDs are shorter and URL-safe without escaping. A ULID encodes its creation time, which a UUIDv4 does not — useful for ordering and debugging, but worth noting if you would rather not expose when a record was made. Both are 128 bits and both avoid coordination, so collision risk is negligible for either. If your stack standardizes on UUIDs but you still want time-ordering, UUIDv7 (from the UUID Generator) offers a similar time-prefixed design in UUID format — or you can generate ULIDs here and convert them to UUID with the Convert tab. **Q: Are ULIDs sortable?** A: Yes — that is the defining feature. Because the 48-bit millisecond timestamp occupies the first 10 characters and Crockford's Base32 preserves lexicographic order, sorting ULIDs as ordinary strings sorts them by creation time. This holds in any system that compares strings byte by byte: a database ORDER BY, a sorted set, a file listing, or a simple array sort. The practical payoff is database performance: time-ordered keys append to the end of a B-tree index instead of scattering randomly like UUIDv4, which keeps inserts fast and the index compact. Within a single millisecond the ordering of plain ULIDs is random, so if you need strict ordering even for IDs minted in the same millisecond, use the monotonic mode, which increments the randomness so each value is guaranteed greater than the last. **Q: How do I decode a ULID's timestamp?** A: Paste the ULID into the Decode tab and the tool extracts the embedded creation time instantly, entirely in your browser. It reads the first 10 characters, converts them from Crockford's Base32 back to a 48-bit integer of milliseconds since the Unix epoch, and shows that moment in UTC and your local time along with the raw Unix-millisecond value. For example, the canonical ULID 01ARYZ6S41TSV4RRFFQ69G5FAV decodes to 1469918176385 ms, or 2016-07-30T22:36:16.385Z. The remaining 16 characters are the 80-bit randomness and carry no meaning to decode. Reading the timestamp this way is handy for debugging, auditing when a record was created, or sanity-checking that an identifier really is a ULID — no database query required. **Q: What is a monotonic ULID?** A: A monotonic ULID guarantees strict ordering even for identifiers generated within the same millisecond. Plain ULIDs created in one millisecond share the same 10-character time prefix, but their 80-bit random tails are independent, so their relative order is not defined. Monotonic generation solves this: the first ULID in a given millisecond gets fresh randomness, and each subsequent ULID in that same millisecond is produced by incrementing the previous randomness by one. The result is a sequence where every value is strictly greater than the one before it, so a batch inserted in a tight loop stays perfectly sorted. This matters for high-throughput systems — event logs, message queues, bulk imports — where many rows can be created faster than the millisecond clock ticks and you still need a stable, increasing key. **Q: Is this ULID generator secure and private?** A: Yes on both counts. The randomness in every ULID comes from crypto.getRandomValues, the browser's cryptographically secure random number generator — never Math.random — so the 80 random bits are unpredictable and the chance of two ULIDs colliding within the same millisecond is vanishingly small. Just as important, everything runs locally: the ULIDs are generated, decoded, and converted entirely on your device. Nothing is uploaded, logged, or stored, and you can confirm it by opening DevTools and watching the Network tab stay silent while you click Generate. That privacy property is the whole reason to create identifiers in the browser rather than on a server that could, in principle, keep a copy of every value it hands out. **Q: What is the difference between ULID and UUIDv7?** A: Both ULID and UUIDv7 are time-ordered 128-bit identifiers that put a millisecond timestamp first, so both sort by creation time and both index efficiently — the core idea is the same. The difference is format and encoding. A ULID is presented as 26 characters of Crockford's Base32 with no hyphens, which is shorter and URL-safe; UUIDv7 is presented in the standard 36-character hyphenated hexadecimal UUID layout and carries version and variant bits in fixed positions, so it is a fully valid RFC 9562 UUID that any UUID library accepts. Choose UUIDv7 when you must remain in the UUID ecosystem (a UUID database column, a UUID-typed API); choose ULID when you want the shortest sortable string. Since both are 128 bits, you can generate a ULID here and convert it to UUID form with the Convert tab, or generate a UUIDv7 with the UUID Generator. For a deeper side-by-side of ULID, UUIDv4, UUIDv7, and Snowflake IDs, see our guide to sortable unique identifiers. --- ### Unicode Converter URL: https://go-tools.org/tools/unicode-converter Paste any Unicode form and read it back as text. \uXXXX escapes, ES6 braces, U+ code points, entities and byte runs are recognised automatically, then every other representation is listed at once. Runs in your browser. #### What is a Unicode escape? A Unicode escape writes a character using only ASCII, so it survives systems that cannot carry the character itself. The same character has a different escape in almost every language: JavaScript and JSON use four hex digits per UTF-16 unit, ES6 and Rust take a full code point in braces, Python and Go add a wide eight-digit form, CSS uses a bare backslash, and HTML has its own numeric and named references. They all describe the same code point, which is why one string can arrive at you in half a dozen shapes. ``` 中文 U+4E2D U+6587 code point \u4E2D\u6587 JavaScript / Java / JSON \u{4E2D}\u{6587} ES6 / Rust E4 B8 AD E6 96 87 UTF-8 %E4%B8%AD%E6%96%87 URL 中文 HTML ``` #### FAQ **Q: What does \u4e2d\u6587 mean and how do I read it?** A: Each \uXXXX is one UTF-16 code unit written in hexadecimal. \u4e2d is U+4E2D and \u6587 is U+6587, which together spell a Chinese word. Paste the whole string above and the readable text comes back; surrounding JSON or log text is preserved untouched. **Q: The backslashes were stripped and I only have u4e2d left. Can that still be decoded?** A: Yes. Terminals and log pipelines often swallow backslashes. Bare u4e2du6587 is recognised and decoded, while ordinary words that merely contain a u are left alone. **Q: Why is one emoji written as two \u escapes?** A: Characters above U+FFFF do not fit in a single UTF-16 code unit, so JavaScript, Java and JSON write them as a surrogate pair. A grinning face is one code point, two UTF-16 units and four UTF-8 bytes. The character table shows all three counts. **Q: How do I go the other way and turn text into escapes?** A: Type or paste plain text and read the table below the result. Every representation is produced at once, so you can copy the exact form your language expects instead of converting twice. **Q: Two strings look identical but my code says they are different. Why?** A: They are probably normalised differently. An accented letter can be one code point or a base letter plus a combining mark; both render the same but are not equal. Use the NFC button to fold them together. Note that normalisation is not a no-op for CJK either — compatibility ideographs change under plain NFC. **Q: Something invisible in my string is breaking my code. How do I find it?** A: Turn on Reveal invisible characters. Byte order marks, zero-width spaces, non-breaking spaces and variation selectors get a visible stand-in, and the character table names each one and gives its bytes. **Q: Is my data uploaded anywhere?** A: No. Conversion happens in your browser with no network request. Nothing is uploaded, logged or stored, so pasting production logs is safe. --- ### Unix Timestamp & Epoch Converter — Multi-Precision URL: https://go-tools.org/tools/unix-timestamp-converter Convert Unix timestamps to dates instantly. Auto-detects seconds, milliseconds & microseconds. Live clock, bidirectional. Free & private. #### What Is a Unix Timestamp (Epoch Time)? A Unix timestamp (also called Epoch time or POSIX time) is the number of seconds elapsed since January 1, 1970 00:00:00 UTC, serving as the universal time reference for virtually all computing systems. From Linux kernels and SQL databases to JavaScript engines and mobile operating systems, virtually every modern platform stores and exchanges time as a Unix timestamp. As IEEE Std 1003.1 (POSIX) formally defines it: "The Unix epoch (January 1, 1970 00:00:00 UTC) serves as the zero-point for POSIX time" — a convention so universally adopted that it is now the de facto standard for machine-readable timestamps worldwide. Unix timestamps are used by the overwhelming majority of server-side systems, databases, and network protocols, including HTTP headers, JWT tokens, and virtually every REST API. The Unix epoch itself — January 1, 1970 — was not chosen arbitrarily. Unix was developed at Bell Labs in the late 1960s, and 1970 was a convenient, round starting point that was recent enough to represent all relevant dates with manageable integer sizes. Any moment in time can be expressed as the signed 64-bit integer count of seconds from that anchor point. Dates before the epoch are represented as negative numbers: December 31, 1969 at midnight UTC is -86400 (one day, or 86,400 seconds, before the epoch). Modern systems often need finer time resolution than whole seconds. To accommodate this, timestamps are commonly expressed in milliseconds (thousandths of a second, as returned by JavaScript's `Date.now()` or Java's `System.currentTimeMillis()`) or microseconds (millionths of a second, used in databases like PostgreSQL and in high-frequency trading systems). You can identify the precision by the number of digits: 10 digits indicates seconds, 13 digits indicates milliseconds, and 16 digits indicates microseconds. This converter auto-detects your input's precision automatically. Unix timestamps are the backbone of distributed computing because they are timezone-independent, monotonically increasing (under normal conditions), and trivially sortable as integers. Storing times as timestamps and converting to human-readable formats only at display time is a best practice that eliminates entire categories of timezone bugs. The tradeoff is readability — a raw timestamp like 1741965432 is opaque without a converter, which is exactly what this tool provides. All conversions happen entirely in your browser using the JavaScript Date API — no timestamps, dates, or any other data are ever sent to a server. This tool converts any Unix timestamp — including the current epoch time shown in the live clock above — to a human-readable date instantly, with complete privacy. Timestamps are closely related to other developer tools. UUID v1 and v7 embed timestamps directly within their identifiers, and API responses containing timestamps are often best inspected using a JSON formatter for readability. For an in-depth guide covering precision, timezone handling, and DST pitfalls with code examples in JavaScript, Python, and Go, read our Unix timestamp guide. ``` // Get the current Unix timestamp in JavaScript const timestampSeconds = Math.floor(Date.now() / 1000); console.log(timestampSeconds); // → 1741965432 // Milliseconds (native JavaScript) const timestampMs = Date.now(); console.log(timestampMs); // → 1741965432000 // Convert timestamp back to a Date object const date = new Date(timestampSeconds * 1000); console.log(date.toISOString()); // → '2025-03-14T15:37:12.000Z' // Python equivalent // import time // timestamp = int(time.time()) # → 1741965432 ``` #### FAQ **Q: Why does Unix time start from January 1, 1970?** A: The Unix epoch date of January 1, 1970 was chosen by the developers of Unix at Bell Labs in the late 1960s as a convenient round starting point that was both recent and computationally practical. At the time, timestamps were stored in 32-bit integers, so the epoch needed to be close enough to the present that common dates would fit in a reasonably sized number. 1970 was simply a clean round year that was after the system's development began. There is no deep technical significance to January 1, 1970 specifically — it was an engineering pragmatism. Other systems have chosen different epochs: the Macintosh classic toolbox used January 1, 1904; Windows NT uses January 1, 1601; GPS time starts from January 6, 1980. Each reflects the era and design constraints of the system that chose it. What made the Unix epoch stick is that Unix became the dominant operating system in computing, and every major programming language, database, and operating system eventually adopted Unix time as the universal standard for representing machine-readable timestamps. Today, the Unix epoch is effectively a universal constant in computing, recognized by every major platform from Linux kernels to JavaScript engines to SQL databases. The choice has one well-known consequence: dates before January 1, 1970 are represented as negative numbers, which some older systems cannot handle. For historical dates and astronomical calculations, alternative timestamp formats are sometimes preferred. For the vast majority of software development, however, the Unix epoch covers all relevant dates comfortably. **Q: What is the Year 2038 problem?** A: The Year 2038 problem (also called Y2K38 or the Epochalypse) is a computing issue that will affect systems storing Unix timestamps as signed 32-bit integers. A signed 32-bit integer can hold values from -2,147,483,648 to 2,147,483,647. When interpreted as a Unix timestamp, the maximum value of 2,147,483,647 corresponds to January 19, 2038 at 03:14:07 UTC. One second later, the counter will overflow and wrap around to the most negative representable value, which corresponds to December 13, 1901 — causing these systems to interpret future dates as being in the far past. The consequences can range from trivial to catastrophic depending on how timestamps are used. Systems might reject valid future dates during input validation, incorrectly sort time-sensitive records, miscalculate expiration dates for certificates and tokens, or crash entirely when encountering the overflow value. The fix is straightforward: migrate to 64-bit signed integers for timestamp storage. A 64-bit timestamp can represent dates approximately 292 billion years before and after the epoch — far beyond any practical concern. Most modern operating systems, programming languages, and databases already use 64-bit timestamps internally. The risk lies in legacy code, embedded systems, 32-bit operating systems still in production, file system metadata (such as FAT32's timestamp fields), and database columns defined as INT rather than BIGINT. Developers should audit their systems now. The migration from 32-bit to 64-bit timestamps must happen before 2038, and in practice, any systems with long-running records (mortgages, infrastructure assets, legal documents) may encounter the problem much sooner as future dates are entered into affected fields. **Q: What is the difference between seconds, milliseconds, and microseconds timestamps?** A: Unix timestamps come in three common precisions, distinguished by the number of digits in the value: **Seconds (10 digits)**: The original and most common Unix timestamp format. `1741965432` represents a specific second in time. Used by: Unix/Linux system calls (`time()`), most Unix utilities, JWT tokens (`iat`, `exp` claims), HTTP headers (`Last-Modified`), and many REST APIs. The current timestamp is approximately 10 digits long. **Milliseconds (13 digits)**: One thousandth of a second precision. `1741965432000` is the same moment as above, multiplied by 1,000. Used by: JavaScript's `Date.now()`, Java's `System.currentTimeMillis()`, Node.js, most modern JavaScript/TypeScript APIs, Redis, and many database clients. When you see a 13-digit timestamp in a JSON API response, it is almost certainly milliseconds. **Microseconds (16 digits)**: One millionth of a second precision. `1741965432000000` is the same moment multiplied by 1,000,000. Used by: PostgreSQL's `TIMESTAMP` and `TIMESTAMPTZ` types, Python's `time.time_ns()` (though that returns nanoseconds), high-frequency trading systems, and network packet analysis tools. The most common mistake is mixing precisions — for example, passing a millisecond timestamp to a function that expects seconds. This produces dates roughly 11,574 years in the future. Always check the documentation of the API or system you are working with to confirm the expected precision, and use this converter's auto-detection as a sanity check. **Q: Does Unix time account for leap seconds?** A: No — Unix time does not account for leap seconds, and this is one of its known limitations for precision timekeeping applications. Leap seconds are occasionally inserted (or theoretically removed, though none have been removed yet) by the International Earth Rotation and Reference Systems Service (IERS) to keep UTC synchronized with the Earth's slightly irregular rotation. As of 2026, 27 leap seconds have been inserted since they were first introduced in 1972. Unix time assumes a perfectly regular calendar with exactly 86,400 seconds per day (24 × 60 × 60). When a leap second is inserted, the real world has a second that Unix time ignores. Different operating systems handle this differently: Linux traditionally "smears" the leap second by running the clock slightly slow for a period around the insertion point (Google's approach, also called "leap smearing"); some systems duplicate the second at 23:59:60 UTC; others simply skip the adjustment and let the clock drift. For the overwhelming majority of software applications — web services, APIs, databases, business logic — the ~27 seconds of accumulated leap second discrepancy over 50+ years is completely irrelevant. The difference is imperceptible to any human-facing application. Where leap seconds matter: GPS synchronization, astronomical observation, packet network timing protocols (PTP/IEEE 1588), and any system that must correlate Unix timestamps with TAI (International Atomic Time) precisely. If your application falls into these categories, you should use a timekeeping library that explicitly supports leap second awareness, or work with TAI timestamps directly. **Q: Can Unix timestamps be negative?** A: Yes, Unix timestamps can be negative, and negative timestamps are a legitimate and well-defined way to represent dates before the Unix epoch (January 1, 1970, 00:00:00 UTC). Each second before the epoch corresponds to a decrement of 1 from zero. For example, -1 represents December 31, 1969 at 23:59:59 UTC; -86400 represents December 31, 1969 at 00:00:00 UTC (exactly one day before the epoch); and -2208988800 represents January 1, 1900 at 00:00:00 UTC. Most modern programming languages and operating systems support negative timestamps. Python's `datetime.fromtimestamp(-86400)` correctly returns December 31, 1969. JavaScript's `new Date(-86400 * 1000)` correctly renders the same date. PostgreSQL stores timestamps as 8-byte integers and correctly handles dates thousands of years before the epoch. However, there are important caveats. Some older systems, libraries, or database drivers may not support negative timestamps correctly. 32-bit systems using unsigned integers for timestamps cannot represent negative values at all. Some databases defined as UNSIGNED BIGINT or DATETIME types may reject negative values or interpret them as far-future dates. For historical dates (anything before 1970), it is often safer to store the date as an ISO 8601 string or use a database-native date type rather than relying on negative Unix timestamps for portability. This converter handles negative timestamps correctly and will display the corresponding pre-1970 date. **Q: How do I get the current Unix timestamp in JavaScript, Python, or other languages?** A: Getting the current Unix timestamp is straightforward in every major programming language: **JavaScript / TypeScript:** ```javascript // Seconds (most APIs expect this) const seconds = Math.floor(Date.now() / 1000); // Milliseconds (JavaScript native) const milliseconds = Date.now(); ``` **Python:** ```python import time seconds = int(time.time()) # 1741965432 import datetime milliseconds = int(datetime.datetime.now(datetime.UTC).timestamp() * 1000) ``` **Go:** ```go import "time" seconds := time.Now().Unix() // int64 milliseconds := time.Now().UnixMilli() // int64 microseconds := time.Now().UnixMicro() // int64 ``` **Java:** ```java long seconds = System.currentTimeMillis() / 1000L; long milliseconds = System.currentTimeMillis(); // Or with java.time (Java 8+): long seconds2 = Instant.now().getEpochSecond(); ``` **PHP:** ```php $seconds = time(); // integer $milliseconds = round(microtime(true) * 1000); ``` **Ruby:** ```ruby seconds = Time.now.to_i milliseconds = (Time.now.to_f * 1000).to_i ``` **Bash / Shell:** ```bash date +%s # seconds date +%s%3N # milliseconds (GNU date) ``` The most important thing to remember is that JavaScript works natively in milliseconds, while virtually every other language defaults to seconds. Always be explicit about which precision you are using, and document it in your API contracts to prevent integration bugs. **Q: How do I convert epoch time to a human-readable date?** A: There are three fast ways to convert epoch time (Unix timestamps) to a human-readable date: **1. Use this online converter (fastest)** Paste your epoch timestamp into the input field above. The tool auto-detects whether it is in seconds, milliseconds, or microseconds and instantly displays the result in UTC, your local timezone, ISO 8601, and relative time formats. Click Copy to grab any format. **2. Use code** In JavaScript: `new Date(1741965432 * 1000).toISOString()` returns `'2025-03-14T15:37:12.000Z'`. In Python: `from datetime import datetime, UTC; datetime.fromtimestamp(1741965432, UTC)` returns the same result. Note that JavaScript expects milliseconds while Python expects seconds — the most common source of conversion bugs. **3. Use the command line** On Linux or macOS with GNU date: `date -d @1741965432` (Linux) or `date -r 1741965432` (macOS). On Windows PowerShell: `[DateTimeOffset]::FromUnixTimeSeconds(1741965432).DateTime`. All three methods produce the same result. The online converter above is the fastest option when you just need a quick answer without opening a terminal or writing code. **Q: What is the current Unix timestamp right now?** A: The current Unix timestamp is displayed in the live clock at the top of this page, updating every second. The Unix timestamp is simply the number of seconds since January 1, 1970 00:00:00 UTC, and it increments by exactly 1 each second. To get the current timestamp programmatically: - **JavaScript**: `Math.floor(Date.now() / 1000)` (seconds) or `Date.now()` (milliseconds) - **Python**: `import time; int(time.time())` - **Bash**: `date +%s` As of 2026, the current Unix timestamp is in the 1.77 billion range (10 digits). It will reach 2 billion around May 2033, and the maximum value for 32-bit systems (2,147,483,647) will be reached on January 19, 2038 at 03:14:07 UTC — the so-called Year 2038 problem. Bookmark this page to always have the current epoch time one click away. **Q: I need to debug a timestamp in my API response — how do I convert it?** A: Copy the timestamp value from your API response (it will typically be a 10-digit or 13-digit number in a JSON field like "created_at" or "timestamp"). Paste it directly into the input field above — the tool auto-detects whether it is in seconds or milliseconds and instantly shows the UTC date, your local time, and ISO 8601 format. If the timestamp is nested inside a JWT token, decode the JWT payload (which is Base64URL-encoded) first to extract the iat, exp, or nbf fields, then paste those values here. For batch debugging, use the code snippet: new Date(timestamp * 1000).toISOString() in your browser console to quickly check multiple timestamps without leaving your dev tools. **Q: How do I get the current Unix timestamp in Python/JavaScript/Go?** A: In JavaScript, use Math.floor(Date.now() / 1000) for seconds or Date.now() for milliseconds. In Python, use import time; int(time.time()) for seconds, or int(time.time() * 1000) for milliseconds. In Go, use time.Now().Unix() for seconds, time.Now().UnixMilli() for milliseconds, or time.Now().UnixMicro() for microseconds. Remember that JavaScript natively works in milliseconds while Python and Go default to seconds — this is the single most common source of timestamp bugs when integrating systems written in different languages. Always document which precision your API expects in your OpenAPI/Swagger specification. **Q: What happens to Unix timestamps during daylight saving time changes?** A: Unix timestamps are completely unaffected by daylight saving time (DST) changes because they are based on UTC, which does not observe DST. When clocks "spring forward" or "fall back" in a local timezone, the Unix timestamp continues to increment by exactly 1 per second without any gap or repetition. This is one of the key advantages of storing times as Unix timestamps rather than local datetime strings. However, if you convert a Unix timestamp to a local time during a DST transition, the same local time can correspond to two different Unix timestamps (during the "fall back" hour when clocks repeat). Always store and compare timestamps in UTC, and only convert to local time for display purposes. **Q: I have a timestamp in milliseconds — how do I convert it to seconds?** A: Divide the millisecond timestamp by 1000 and discard the decimal portion. In JavaScript: Math.floor(ms / 1000). In Python: ms // 1000 (integer division). For example, 1741965432000 (milliseconds) becomes 1741965432 (seconds). You can identify millisecond timestamps by their 13-digit length versus the 10-digit length of second timestamps. This tool auto-detects the precision, so you can paste either format directly. The reverse conversion (seconds to milliseconds) is simply multiplication by 1000: 1741965432 * 1000 = 1741965432000. Be careful not to accidentally pass a millisecond value to a function expecting seconds — the result would be a date roughly 11,574 years in the future. --- ### URL Encoder & Decoder with Built-in URL Parser URL: https://go-tools.org/tools/url-decoder-encoder Decode or encode URLs in real time with built-in URL parser. Dual mode: encodeURI & encodeURIComponent. 100% private, no data sent to any server. #### What is URL Encoding (Percent Encoding)? URL encoding, formally known as percent encoding, is a mechanism defined in RFC 3986 for representing characters in a Uniform Resource Identifier (URI) that are not allowed or have special meaning. It converts each unsafe byte into a percent sign (%) followed by two hexadecimal digits — for example, a space becomes %20, an ampersand becomes %26, and the Chinese character 中 becomes %E4%B8%AD (its three UTF-8 bytes, each percent-encoded). URLs can only contain a limited set of characters from the ASCII character set. Letters, digits, and a handful of symbols (- _ . ~) are considered 'unreserved' and can appear as-is. All other characters — including spaces, punctuation, and the entire range of Unicode — must be percent-encoded to be safely transmitted in a URL. Reserved characters like ?, &, =, and # serve as structural delimiters in the URL syntax, so they must also be encoded when used as literal data rather than delimiters. Percent encoding is essential throughout the web: browsers encode form submissions, APIs require encoded query parameters, OAuth flows depend on correctly encoded redirect URIs, and internationalized domain names rely on encoding for non-ASCII characters. Getting encoding wrong leads to broken links, security vulnerabilities (like open redirect attacks), and data corruption. This tool provides both encodeURI and encodeURIComponent modes, a built-in URL structure parser, real-time conversion, and double-encoding detection — all running privately in your browser. URL encoding is often used alongside other web development tools. You might need to Base64-encode a URL for embedding in a JWT token or API payload, or format JSON data that contains URL strings to inspect their structure. For a deeper, byte-level walkthrough of how percent encoding works, read our complete URL encoding guide for developers. Encoding a URL for inclusion inside a QR code? Use the QR Code Generator — long URLs may exceed the QR byte limit, so this tool helps shorten them first. ``` // Encode a query parameter value const param = encodeURIComponent('hello world & goodbye'); console.log(param); // → 'hello%20world%20%26%20goodbye' // Encode a full URL (preserves structure) const url = encodeURI('https://example.com/path name?q=hello world'); console.log(url); // → 'https://example.com/path%20name?q=hello%20world' // Decode a percent-encoded string const decoded = decodeURIComponent('hello%20world%20%26%20goodbye'); console.log(decoded); // → 'hello world & goodbye' // Build a URL with encoded parameters const base = 'https://api.example.com/search'; const query = `?q=${encodeURIComponent('你好')}&lang=zh`; console.log(base + query); // → 'https://api.example.com/search?q=%E4%BD%A0%E5%A5%BD&lang=zh' ``` #### FAQ **Q: What is URL encoding and why is it necessary?** A: URL encoding (percent encoding) converts unsafe characters into %XX hex sequences so they can be safely included in URLs. Characters like spaces, ampersands, and non-ASCII text must be encoded because they would otherwise break URL structure or be misinterpreted by browsers and servers. Defined in RFC 3986, this mechanism works because URLs can only contain a limited set of US-ASCII characters — letters (A-Z, a-z), digits (0-9), and a few symbols like hyphens, underscores, periods, and tildes. Any character outside this safe set is encoded as a percent sign (%) followed by two hexadecimal digits representing the character's byte value. For example, a space becomes %20, a forward slash becomes %2F, and an ampersand becomes %26. Characters like &, =, ?, and # have special structural meaning in URLs — they delimit query parameters, fragments, and other components. Without encoding, a literal & in a parameter value would be misinterpreted as a parameter separator, breaking the URL structure entirely. **Q: What is the difference between encodeURI and encodeURIComponent?** A: encodeURI() encodes a full URL while preserving structural characters like :, /, ?, and #. encodeURIComponent() encodes everything except letters, digits, and - _ . ~, making it the correct choice for encoding individual query parameter values. Use encodeURIComponent() for parameter keys and values, and encodeURI() only for complete URLs. For example, encodeURI('https://example.com/path name') produces 'https://example.com/path%20name', preserving the :// and /. encodeURIComponent() is far more aggressive — it encodes :, /, ?, #, &, and =. If you used encodeURI() on a parameter value that contained an ampersand, the & would pass through unencoded and be misinterpreted as a parameter separator. encodeURIComponent() would correctly encode it as %26. Mixing these up is one of the most common causes of URL-related bugs in web applications. **Q: Is URL encoding the same as HTML encoding?** A: No. URL encoding converts characters to %XX hex sequences for URLs (RFC 3986), while HTML encoding converts characters to entities like & and < for HTML documents. They serve completely different purposes and should never be interchanged. URL encoding is for data transport within URLs — a space becomes %20. HTML encoding is for safely displaying content in HTML — an ampersand becomes &. A common mistake is to apply HTML encoding to URL parameters or vice versa. For example, encoding a space as in a URL would not work — it must be %20 or +. Similarly, using %3C in HTML text instead of < would not achieve the desired escaping. **Q: Why does my URL break when I use it in a curl command?** A: The shell interprets special URL characters before curl sees them: & runs commands in background, ? triggers globbing, and # starts a comment. Fix this by wrapping the URL in single quotes: curl 'https://example.com/api?key=value&page=2#section'. Single quotes prevent the shell from interpreting any special characters. The ampersand (&) is the most common culprit — it tells the shell to run the preceding command in the background, splitting your URL at the first & and discarding everything after it. Alternatively, you can escape individual characters with backslashes, but quoting the entire URL is simpler and less error-prone. If your URL also contains single quotes, use double quotes instead and escape any embedded dollar signs or backticks. **Q: Why do Chinese characters become strings like %E4%B8%AD in URLs?** A: Chinese characters are first converted to UTF-8 bytes, then each byte is percent-encoded as %XX. The character 中 (U+4E2D) becomes three UTF-8 bytes (E4, B8, AD), producing %E4%B8%AD — that's why one Chinese character expands to 9 characters in a URL. This three-step process — character to Unicode code point, code point to UTF-8 bytes, bytes to percent-encoded hex — applies to all non-ASCII characters. Emoji often require 4 UTF-8 bytes and thus expand to 12 characters when percent-encoded. When the URL is decoded, the reverse happens: the hex values are converted back to bytes, the bytes are interpreted as UTF-8, and the original characters are restored. **Q: Should I encode the OAuth redirect_uri parameter?** A: Yes, always encode it with encodeURIComponent(). The redirect_uri is a full URL embedded as a query parameter value, so its special characters (?, &, =) must be encoded to prevent them from being misinterpreted as part of the outer URL's structure. For example, redirect_uri=https://myapp.com/callback?code=abc&state=xyz without encoding would cause the authorization server to see redirect_uri as only https://myapp.com/callback?code=abc, while state=xyz would be parsed as a separate parameter of the outer URL. The correctly encoded version is redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz. **Q: What is the difference between Node.js querystring and URLSearchParams?** A: Use URLSearchParams for new projects — it's the WHATWG standard, matches browser behavior, and works identically in Node.js and browsers. The querystring module is legacy and no longer actively developed. Key differences: URLSearchParams encodes spaces as + (form encoding standard), handles repeated keys via getAll(), and provides an iterable interface with entries(), keys(), and values() methods. The querystring module encodes spaces as %20 and has quirks with array handling (key=1&key=2 becomes { key: ['1', '2'] }). URLSearchParams is standards-compliant and recommended by the Node.js documentation itself. **Q: How do I encode a URL in Python, JavaScript, and Java?** A: JavaScript: encodeURIComponent('hello world') produces 'hello%20world'. Python: urllib.parse.quote('hello world') produces 'hello%20world'. Java: URLEncoder.encode('hello world', StandardCharsets.UTF_8) produces 'hello+world' (replace + with %20 for RFC 3986). In JavaScript, use encodeURIComponent() for parameter values and encodeURI() for full URLs. In Python 3, use urllib.parse.quote() for path segments and urllib.parse.urlencode() for query parameters — urlencode({'q': 'hello world'}) produces 'q=hello+world'. In Java, note that URLEncoder uses form encoding (spaces as +). For building complete URIs, use java.net.URI or the URIBuilder class from Apache HttpClient. **Q: Which characters are not encoded by URL encoding?** A: RFC 3986 defines 66 unreserved characters that never need encoding: A-Z, a-z, 0-9, hyphen (-), period (.), underscore (_), and tilde (~). These can appear literally in any part of a URL. Reserved characters — :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ;, and = — are allowed in their structural roles (like ? for query strings) but must be percent-encoded when used as literal data. In JavaScript, encodeURIComponent() encodes everything except A-Z a-z 0-9 - _ . ~ and ! ' ( ) *, while encodeURI() additionally preserves reserved characters that serve as URL delimiters. **Q: What is the difference between + and %20 for encoding spaces?** A: Both represent a space, but %20 is the universally safe choice. The + convention comes from HTML form encoding (application/x-www-form-urlencoded) and only works in query strings. In URL path segments, + is a literal plus sign, not a space. When in doubt, use %20. The + encoding originates from the HTML specification — when browsers submit forms, spaces become + and the + character itself becomes %2B. The %20 encoding comes from RFC 3986 (URI syntax), where every non-unreserved character is encoded as a percent sign followed by two hex digits. %20 works in all parts of a URL: path, query, and fragment. **Q: How does URL encoding handle emoji?** A: A single emoji typically expands to 12 characters in a URL. Emoji are converted to UTF-8 bytes (usually 4 bytes), then each byte is percent-encoded as %XX. For example, 🚀 (U+1F680) becomes %F0%9F%9A%80. Most emoji use code points in the range U+1F000 to U+1FFFF or higher, which require 4 bytes in UTF-8. Some emoji with skin tone modifiers or ZWJ sequences consist of multiple code points and can expand to 30+ characters when encoded. Despite this expansion, the encoding is fully reversible — decoding %F0%9F%9A%80 correctly produces 🚀. **Q: Can URL encoding be used for encryption or security?** A: No. URL encoding is not encryption and provides zero security. It is a fully reversible, deterministic transformation — anyone can decode a percent-encoded string instantly without any key or secret. It exists solely to escape special characters for safe URL transport. Treating URL encoding as obfuscation or security is a dangerous misconception. Sensitive data like passwords, tokens, or personal information should be protected by HTTPS (TLS encryption of the entire request), not by URL encoding. Additionally, URLs often appear in server logs, browser history, and referrer headers, so sensitive data should generally be sent in request bodies rather than URLs. **Q: What is the maximum length of a URL?** A: There is no official maximum, but keep URLs under 2,000 characters for maximum compatibility. Most browsers support ~2,048 characters, Apache defaults to 8,190 bytes, and Nginx to 8,192 bytes. For large data, use POST requests instead. The HTTP specifications (RFC 7230) do not define a maximum URL length, but practical limits exist at every layer. Chrome and Firefox can handle URLs exceeding 100,000 characters, while IIS limits query strings to 16,384 bytes. CDNs and proxies may have even stricter limits. When URL encoding expands characters — especially non-ASCII text — a seemingly short URL can quickly approach these limits. **Q: What is the difference between a URL and a URI?** A: A URI (Uniform Resource Identifier) is any string that identifies a resource. A URL (Uniform Resource Locator) is a URI that also specifies how to access it via a protocol like https://. All URLs are URIs, but not all URIs are URLs — for example, a URN like urn:isbn:0451450523 identifies a book by ISBN but doesn't tell you where to find it. In everyday web development, the terms URL and URI are often used interchangeably. The encoding rules defined in RFC 3986 apply to both. JavaScript's functions are named encodeURI/decodeURI, reflecting the broader URI terminology, even though most developers work exclusively with URLs. --- ### UUID Generator & Decoder — v1, v4, v5, v7 Batch Mode URL: https://go-tools.org/tools/uuid-generator Free UUID generator — create v1, v4, v5, v7 UUIDs instantly. Decode & validate any UUID. Batch generate up to 50. No signup, 100% browser-based. #### What Is a UUID? A UUID (Universally Unique Identifier) is a 128-bit globally unique identifier standardized by RFC 9562 (IETF, May 2024), designed to generate collision-free IDs across distributed systems without central coordination. UUIDs are the most widely adopted identifier format in modern software — used in database primary keys, API request tracing, session management, and microservice architectures. UUIDs are written as 32 hexadecimal digits in the canonical 8-4-4-4-12 format, such as `550e8400-e29b-41d4-a716-446655440000`. The specification is maintained by the IETF; RFC 9562 supersedes the earlier RFC 4122 (2005) and formally introduces UUID versions 6, 7, and 8. There are five widely used UUID versions. Version 1 (v1) encodes the current timestamp and the generating machine's MAC address, making each UUID unique in both time and space. Version 3 (v3) and version 5 (v5) are deterministic — they hash a namespace and a name using MD5 or SHA-1 respectively, always producing the same UUID for the same inputs. Version 4 (v4) is the most common: it fills 122 bits with cryptographically secure random data, giving over 5.3 × 10³⁶ possible values (RFC 9562, Section 5.4). Version 7 (v7) is the newest standard: as RFC 9562 Section 5.7 states, "UUID version 7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source" — combining a 48-bit millisecond timestamp with random data to produce UUIDs that are both unique and naturally sortable by creation time. UUIDs are essential in distributed systems, databases, APIs, and anywhere unique identifiers are needed without centralized coordination. They eliminate the risk of ID collisions across independent systems, making them ideal for microservices, event sourcing, and multi-tenant architectures. This tool generates all UUID versions entirely in your browser using the Web Crypto API — no UUIDs are transmitted to any server. Unlike server-based generators, there are no uploads, no logging, and no data retention. Safe to use for production database keys, API identifiers, and security-sensitive applications. You can also decode and validate existing UUIDs to inspect their version, variant, and embedded data. UUIDs are closely connected to other developer primitives. UUID v1 and v7 embed Unix timestamps directly, UUID v3 and v5 use MD5 and SHA-1 hashes as their foundation, and UUID strings are often transported inside JSON payloads best inspected with a JSON formatter. For a thorough introduction to UUID format, versions, and real-world use cases, read our complete UUID guide. If you are choosing between UUID v4, v7, ULID, and Snowflake IDs for a database primary key, see our ID selection comparison. ``` // Generate a UUID v4 using the Web Crypto API const uuid = crypto.randomUUID(); console.log(uuid); // → '550e8400-e29b-41d4-a716-446655440000' // Manual v4 generation with crypto.getRandomValues() function generateUUIDv4() { const bytes = new Uint8Array(16); crypto.getRandomValues(bytes); bytes[6] = (bytes[6] & 0x0f) | 0x40; // version 4 bytes[8] = (bytes[8] & 0x3f) | 0x80; // variant 10 const hex = Array.from(bytes, b => b.toString(16).padStart(2, '0')).join(''); return `${hex.slice(0,8)}-${hex.slice(8,12)}-${hex.slice(12,16)}-${hex.slice(16,20)}-${hex.slice(20)}`; } ``` #### FAQ **Q: What is a UUID?** A: A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 9562. It is written as 32 hexadecimal digits displayed in five groups separated by hyphens, following the 8-4-4-4-12 format — for example, 550e8400-e29b-41d4-a716-446655440000. UUIDs are designed to be globally unique without requiring a central registration authority. The term GUID (Globally Unique Identifier) is Microsoft's name for the same concept and uses the identical format. UUIDs are used extensively in databases, distributed systems, APIs, and software development wherever unique identifiers are needed. With over 5.3 x 10^36 possible v4 UUIDs, the probability of generating a duplicate is astronomically small, making them safe for independent generation across uncoordinated systems. **Q: What are the differences between UUID versions?** A: UUID v1 encodes a 60-bit timestamp and the machine's 48-bit MAC address, guaranteeing uniqueness in time and space but potentially leaking hardware identity. UUID v3 hashes a namespace and name with MD5 to produce a deterministic UUID — the same inputs always yield the same output. UUID v4 fills 122 of its 128 bits with cryptographically secure random data, making it the most widely used version for general-purpose unique identifiers. UUID v5 is identical to v3 but uses SHA-1 instead of MD5, offering stronger hash collision resistance. UUID v7, introduced in RFC 9562 (May 2024), embeds a 48-bit Unix timestamp in milliseconds followed by random bits, producing UUIDs that are both unique and naturally sortable by creation time. Version choice depends on your requirements: v4 for simplicity, v5 for determinism, and v7 for time-sortable database keys. **Q: When should I use UUID v4 vs v7?** A: UUID v4 is the most popular version and an excellent default choice. It generates 122 bits of pure randomness, requires no configuration, and works everywhere. Use v4 when you simply need a unique identifier and don't care about ordering. UUID v7 is the better choice when UUIDs will be used as database primary keys or need to be sorted by creation time. Because v7 embeds a millisecond-precision timestamp in the most significant bits, v7 UUIDs naturally sort in chronological order. This property dramatically improves B-tree index performance — inserts always go to the end of the index rather than random positions, reducing page splits and fragmentation by up to 90%. For new projects in 2026, the general recommendation is to use v7 for database keys and v4 for everything else. Both versions are equally unique and cryptographically random in their random portions. **Q: What is the probability of UUID collision?** A: UUID v4 has 122 random bits, giving 2^122 (approximately 5.3 x 10^36) possible values. To have a 50% probability of at least one collision, you would need to generate approximately 2.71 x 10^18 UUIDs — that is 2.71 quintillion. To put this in perspective, if you generated one billion UUIDs per second, it would take about 86 years to reach a 50% collision probability. At more realistic generation rates, the probability is vanishingly small. For example, generating 10 million UUIDs produces a collision probability of roughly 1 in 10^22. In practice, hardware failures, software bugs, and human errors are all billions of times more likely to cause duplicate IDs than UUID v4 collisions. The math is based on the birthday problem formula: p(n) approximately equals n^2 / (2 * 2^122). **Q: What is the difference between UUID and GUID?** A: UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) are essentially the same thing. GUID is the term coined by Microsoft and used predominantly in Windows, .NET, COM, and SQL Server environments. UUID is the standard term defined by RFC 9562 (and its predecessor RFC 4122) and is used in most other contexts including Linux, Java, Python, PostgreSQL, and web development. Both use the identical 128-bit format displayed as 32 hexadecimal digits in the 8-4-4-4-12 pattern. The only minor difference is that Microsoft tools sometimes display GUIDs in uppercase with curly braces, like {550E8400-E29B-41D4-A716-446655440000}, while UUIDs are conventionally shown in lowercase without braces. This tool supports both formats via the output format selector — choose the Braces {GUID} format for Microsoft-style output. **Q: Is UUID v4 cryptographically secure?** A: When generated using crypto.getRandomValues() or an equivalent CSPRNG (Cryptographically Secure Pseudo-Random Number Generator), UUID v4 contains 122 bits of cryptographically secure random data. This tool uses the Web Crypto API, which draws entropy from the operating system's secure random source. However, UUIDs should not be used as security tokens, passwords, or encryption keys. While 122 bits of randomness makes prediction infeasible, UUIDs have a predictable structure — the version nibble (4) and variant bits are fixed and publicly known. For security tokens, use purpose-built APIs like crypto.getRandomValues() with a full 128 or 256 bits of entropy, or use established token formats like JWT. Use UUIDs for identification, not for security. **Q: How to validate a UUID format?** A: A valid UUID matches the regular expression pattern: ^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$ (case-insensitive). This pattern enforces the 8-4-4-4-12 hexadecimal format, checks that the version digit (position 15) is between 1 and 7, and verifies that the variant nibble (position 20) starts with 8, 9, a, or b (indicating the RFC 4122/9562 variant). In JavaScript, you can validate with: /^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.test(uuid). Most programming languages also have built-in UUID parsing — for example, Python's uuid.UUID() constructor, Java's UUID.fromString(), and Go's uuid.Parse(). Always validate UUIDs at system boundaries before storing or processing them to prevent injection attacks and data corruption. **Q: Are UUIDs good database primary keys? (Performance, safety & best version)** A: Yes, UUIDs are safe and increasingly popular as database primary keys, with UUID v7 being the recommended version. The key advantages: (1) UUIDs can be generated anywhere — clients, servers, or edge functions — without a round trip to the database, enabling offline-first and distributed architectures. (2) UUIDs prevent enumeration attacks since they are not sequential integers. (3) UUIDs simplify data merging across systems since IDs never collide. UUID v7 is the best version for primary keys because its time-ordered structure keeps B-tree indexes sequential, dramatically reducing page splits, write amplification, and index fragmentation by up to 90% compared to random v4 UUIDs. The tradeoffs: UUIDs use 16 bytes versus 4-8 bytes for integers, increasing storage and memory for indexes. In MySQL/InnoDB, where the primary key is the clustered index, random v4 UUIDs can cause significant performance degradation — v7 solves this by ensuring inserts always append to the end of the index, achieving performance comparable to auto-increment integers. PostgreSQL stores UUIDs natively in 16 bytes with the uuid type. For most modern applications, the benefits of globally unique, coordination-free ID generation far outweigh the extra storage cost. **Q: What is a namespace UUID (v3/v5)?** A: A namespace UUID is a predefined or custom UUID that serves as a scope for generating deterministic v3 and v5 UUIDs. RFC 4122 defines four standard namespace UUIDs: DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8), URL (6ba7b811-9dad-11d1-80b4-00c04fd430c8), OID (6ba7b812-9dad-11d1-80b4-00c04fd430c8), and X.500 DN (6ba7b814-9dad-11d1-80b4-00c04fd430c8). When you combine a namespace UUID with a name string, the v3 or v5 algorithm hashes them together to produce a deterministic UUID — the same namespace plus name always produces the same UUID. This is useful when you need reproducible identifiers derived from meaningful names. For example, hashing the DNS namespace with 'example.com' always yields the same v5 UUID. You can also use any valid UUID as a custom namespace for your application's own deterministic ID scheme. **Q: What is the UUID nil value?** A: The nil UUID (also called the zero UUID) is 00000000-0000-0000-0000-000000000000 — all 128 bits set to zero. It is defined in RFC 9562 Section 5.9 as a special UUID that can represent the absence of a value, similar to null or None in programming languages. The nil UUID is useful as a sentinel value, a default in configuration systems, or a placeholder in database records where a UUID field must not be empty but no real value exists yet. RFC 9562 also defines the max UUID: ffffffff-ffff-ffff-ffff-ffffffffffff (all bits set to one), which can serve as a boundary marker. Important caveats: never use the nil UUID as an actual identifier — it is not unique. Some UUID libraries and databases may reject or specially handle nil UUIDs, so ensure your system treats them consistently. Always document whether nil UUIDs are accepted in your API contracts and database schemas. **Q: What is UUID v7 and why should I use it?** A: UUID v7 is the newest UUID version defined in RFC 9562 (May 2024). It embeds a 48-bit Unix timestamp in milliseconds in the most significant bits, followed by cryptographically random data. This design produces UUIDs that are globally unique, chronologically sortable, and highly efficient as database primary keys. Unlike UUID v1, which also contains a timestamp, v7 uses a simpler Unix epoch format and does not expose your MAC address. The time-ordered structure reduces B-tree index fragmentation by up to 90% compared to random UUID v4, resulting in faster inserts, smaller indexes, and better cache hit rates. For new projects starting in 2026, UUID v7 is the recommended choice for any scenario requiring time-based ordering — especially database primary keys, event logs, and distributed message queues. **Q: How to decode a UUID?** A: Decoding a UUID means extracting the structural information encoded within its 128 bits. Every UUID contains a version field (bits 48-51) identifying how it was generated, and a variant field (bits 64-65) identifying the UUID standard it conforms to. Beyond these common fields, different versions embed different data: UUID v1 and v6 contain a 60-bit timestamp and a 48-bit node (MAC address); UUID v7 contains a 48-bit Unix timestamp in milliseconds; UUID v3 and v5 contain a truncated hash of a namespace and name. To decode a UUID, paste it into the Decode tab of this tool. It will instantly display the version, variant, timestamp (for time-based versions), and validity status. Programmatically, you can decode by parsing the hex digits and applying bitwise operations to extract each field according to the RFC 9562 specification. **Q: UUID vs ULID vs nanoid — which should I use?** A: UUID, ULID, and nanoid serve the same fundamental purpose — generating unique identifiers — but differ in format, sortability, and standardization. UUID is the most widely adopted standard (RFC 9562), supported natively by virtually all databases, languages, and frameworks. UUID v7 provides time-based sorting in the standard 128-bit, 36-character format. ULID (Universally Unique Lexicographically Sortable Identifier) predates UUID v7 and uses Crockford Base32 encoding to produce a 26-character, sortable string. Now that UUID v7 exists as an IETF standard, ULID's main advantage — sortability — is available in the universal UUID format. nanoid generates shorter identifiers (default 21 characters) using a URL-safe alphabet, making it ideal when string length matters and you don't need cross-system interoperability. For most applications, UUID v4 (general purpose) or UUID v7 (database keys) is the recommended choice due to universal tooling support, native database types, and formal standardization. **Q: I'm building a microservice and need to choose between UUID v4 and v7 for my PostgreSQL primary keys — which one should I use and why?** A: Use UUID v7 for PostgreSQL primary keys. UUID v7 embeds a millisecond-precision Unix timestamp in the most significant bits, so generated IDs are naturally chronologically sorted. This keeps your B-tree indexes sequential — inserts always append to the end rather than landing at random positions, reducing page splits and index fragmentation by up to 90% compared to random UUID v4. PostgreSQL 17+ has native uuid type support optimized for this pattern. UUID v4 is still fine for non-indexed identifiers like correlation IDs or session tokens where sort order doesn't matter. **Q: My team is debating whether to use UUIDs or auto-increment integers as database IDs — what are the real-world tradeoffs?** A: Auto-increment integers are smaller (4-8 bytes vs 16 bytes), faster to compare, and produce naturally sequential indexes. However, they require a centralized sequence (the database), making them problematic in distributed systems, offline-first apps, and data migrations. UUIDs can be generated anywhere — clients, edge functions, multiple databases — without coordination. They also prevent enumeration attacks (users can't guess /users/124 to find other records). The storage overhead is real but usually acceptable: a UUID index is roughly 2x the size of an integer index. For most modern applications, UUID v7 offers the best of both worlds — globally unique, coordination-free, and sequentially sortable like auto-increments. --- ### Volume & Liquid Measurement Converter — 15 Units URL: https://go-tools.org/tools/volume-converter Convert volume & liquid capacity between 15 units — metric, US customary, imperial & cooking. Free online converter, 100% private, runs in your browser. #### What Is a Volume Unit Converter? A volume unit converter is a tool that translates capacity and volume measurements between different units of measure — spanning metric (milliliters, liters, cubic meters), US customary (cups, pints, quarts, gallons, fluid ounces, tablespoons, teaspoons), Imperial (Imperial gallons, Imperial fluid ounces), and cubic measurements (cubic inches, cubic feet). The metric system defines volume through the liter. By exact SI definition (BIPM), 1 liter equals exactly 1 cubic decimeter (dm³) — which means 1 milliliter equals exactly 1 cubic centimeter (cm³). This elegant equivalence makes the metric system especially practical: a liter of water at 4 °C weighs almost exactly 1 kilogram, linking volume and mass directly. The US customary system uses a hierarchy: 1 gallon = 4 quarts = 8 pints = 16 cups = 128 fluid ounces. The Imperial system (used in the UK) shares some unit names with the US system but with different sizes — an Imperial gallon is about 20% larger than a US gallon (4,546 mL vs 3,785 mL). Cooking measurements add further complexity: US recipes use cups, tablespoons, and teaspoons, while most of the world measures by weight (grams) or metric volume (milliliters). This converter handles all these systems, including the often-confused distinction between US and Imperial fluid ounces (29.57 mL vs 28.41 mL). All conversions use the exact factors defined by NIST Handbook 44 and the BIPM SI Brochure, and are calculated entirely in your browser — no data is transmitted to any server, so your values stay completely private. Need to convert other measurement types? Try our length converter for distance units, weight converter for mass units, or temperature converter for Celsius, Fahrenheit, and Kelvin. ``` // Key volume conversion factors: // 1 liter = 1000 mL // 1 US gallon = 3785.411784 mL // 1 US cup = 236.588 mL // 1 US fl oz = 29.5735 mL // 1 US tbsp = 14.787 mL // 1 US tsp = 4.929 mL // JavaScript conversion examples: const litersToGallons = (l) => l / 3.785411784; const cupsToMl = (cups) => cups * 236.5882365; const tbspToTsp = (tbsp) => tbsp * 3; console.log(litersToGallons(3.785)); // ~1.0 console.log(cupsToMl(2)); // 473.176 console.log(tbspToTsp(3)); // 9 ``` #### FAQ **Q: How many milliliters are in a cup?** A: One US cup equals approximately 236.588 milliliters. This is based on the US customary system where 1 cup = 8 fluid ounces = 16 tablespoons. For quick mental math, round to 240 mL — many measuring cups sold outside the US use this rounded value. Note that the metric cup (used in Australia) is exactly 250 mL, and the Imperial cup (UK, Canada historical) is about 284 mL. **Q: What is the difference between a US gallon and an Imperial gallon?** A: A US gallon contains 3,785.41 mL (128 US fluid ounces), while an Imperial gallon contains 4,546.09 mL (160 Imperial fluid ounces). The Imperial gallon is about 20% larger. This means a US vehicle getting 30 miles per US gallon would get about 36 miles per Imperial gallon. The difference originated from different historical definitions of the gallon in the US and British systems. **Q: How many liters are in a gallon?** A: One US gallon equals exactly 3.785411784 liters. One Imperial gallon equals exactly 4.54609 liters. For a quick US gallon approximation, remember that 1 gallon is roughly 3.8 liters, or that 4 liters is slightly more than 1 gallon. Common reference: a standard 2-liter soda bottle is about half a US gallon. **Q: How do I convert between tablespoons and teaspoons?** A: One US tablespoon equals exactly 3 US teaspoons. So to convert tablespoons to teaspoons, multiply by 3. To convert teaspoons to tablespoons, divide by 3. Other useful relationships: 1 tablespoon = 14.787 mL, 1 teaspoon = 4.929 mL, 1 cup = 16 tablespoons = 48 teaspoons. These are US customary measurements; metric tablespoons and teaspoons may differ slightly. **Q: How many fluid ounces are in a cup?** A: One US cup contains exactly 8 US fluid ounces. This makes cups convenient for scaling: 1/4 cup = 2 fl oz, 1/3 cup = 2.67 fl oz, 1/2 cup = 4 fl oz, 3/4 cup = 6 fl oz. Note that fluid ounces measure volume, not weight — 8 fl oz of water weighs about 8.35 ounces by weight, because water is slightly denser than the standard used to define fluid ounces. **Q: What is a cubic meter in liters?** A: One cubic meter equals exactly 1,000 liters. This relationship is fundamental to the metric system — the liter was originally defined as one cubic decimeter (0.001 m³). This means 1 mL = 1 cm³ exactly. Common conversions: a cubic meter of water weighs 1,000 kg (1 metric ton) at standard conditions, a typical bathtub holds about 0.15-0.3 m³ (150-300 liters). **Q: How accurate is this volume converter?** A: This converter uses the exact US customary and metric conversion factors defined by NIST (National Institute of Standards and Technology). All calculations use IEEE 754 double-precision floating-point arithmetic, providing at least 15 significant digits of precision. For everyday cooking and engineering conversions, the results are far more precise than any physical measurement. The tool runs entirely in your browser with no rounding shortcuts. **Q: Is my data safe when using this volume converter?** A: Yes, completely. All conversions are performed locally in your browser using JavaScript. No data is sent to any server — there are no network requests, no cookies, and no analytics on your input. The conversion logic runs entirely on your device, meaning your values never leave your browser. You can verify this by disconnecting from the internet and using the tool — it works fully offline once the page has loaded. **Q: How do I convert cooking measurements between US and metric?** A: Key cooking conversions: 1 cup = 236.6 mL, 1 tablespoon = 14.8 mL, 1 teaspoon = 4.9 mL, 1 fluid ounce = 29.6 mL. For practical cooking, you can round: 1 cup is about 240 mL, 1 tablespoon is about 15 mL, 1 teaspoon is about 5 mL. When precision matters (baking), use exact values. When it does not (soups, sauces), rounded values work fine. **Q: How many cups are in a quart, pint, and gallon?** A: In the US customary system: 1 gallon = 4 quarts = 8 pints = 16 cups = 128 fluid ounces. Working down: 1 quart = 2 pints = 4 cups = 32 fluid ounces, and 1 pint = 2 cups = 16 fluid ounces. A helpful mnemonic: 'Gallon man' — a gallon contains 4 quarts, each quart contains 2 pints, and each pint contains 2 cups. **Q: I need to convert liters to gallons for my car's fuel tank capacity — how do I do it?** A: Divide the liter value by 3.785 to get US gallons. For example, a 60-liter fuel tank equals about 15.85 US gallons (60 ÷ 3.785 = 15.85). For Imperial gallons (used in the UK), divide by 4.546 — the same 60-liter tank would be about 13.2 Imperial gallons. This matters when comparing fuel economy: a car rated at 8 L/100 km gets about 29.4 miles per US gallon or 35.3 miles per Imperial gallon. Enter any value in this tool to get the precise conversion instantly. **Q: I need to scale a recipe from cups to milliliters — how do I convert cooking measurements?** A: Key conversions: 1 US cup = 236.6 mL, 1 tablespoon = 14.8 mL, 1 teaspoon = 4.9 mL, 1 fluid ounce = 29.6 mL. For practical cooking, round to: 1 cup ≈ 240 mL, 1 tbsp ≈ 15 mL, 1 tsp ≈ 5 mL. To scale a recipe, multiply each measurement by your scaling factor, then convert. For example, to double a recipe calling for 1.5 cups of milk: 1.5 × 2 = 3 cups = 3 × 236.6 = 710 mL. For precise baking (pastry, bread), use grams instead of volume — volume measurements for flour can vary by 20-30% depending on how it is scooped. **Q: I need to figure out how many gallons my aquarium holds based on its dimensions — can this tool help?** A: Yes. First calculate the volume in cubic inches by multiplying length × width × height (all in inches). Then use this tool to convert cubic inches to gallons. For example, a tank that is 36" × 18" × 16" has a volume of 10,368 cubic inches, which equals about 44.9 US gallons. Alternatively, measure in centimeters, calculate cubic centimeters (cm³), and know that 1 cm³ = 1 mL, then convert mL to gallons. A 90 × 45 × 40 cm tank holds 162,000 mL = 162 liters = about 42.8 US gallons. Remember that actual water volume will be slightly less due to substrate, decorations, and equipment. --- ### Weight Converter — kg, lbs, oz, g, Stone & 13 Units Total URL: https://go-tools.org/tools/weight-converter Convert weight between 13 units instantly — metric, imperial & troy. Conversion tables, formulas & references. Free, runs in your browser. #### What Is a Weight & Mass Unit Converter? A weight and mass unit converter is a tool that translates measurements between different units of mass — covering metric (micrograms, milligrams, grams, kilograms, metric tons), avoirdupois/imperial (ounces, pounds, stone, short tons, long tons), and specialty units (carats, troy ounces, grains). The metric system defines mass through the kilogram, the SI base unit. Since the 2019 BIPM redefinition of SI base units, the kilogram has been defined by fixing the numerical value of the Planck constant (h = 6.62607015 × 10⁻³⁴ J·s), replacing the International Prototype of the Kilogram (IPK) — a platinum-iridium cylinder kept in a vault at BIPM near Paris. This redefinition anchors the kilogram to a universal constant of nature. One kilogram = 1,000 grams = 1,000,000 milligrams. The avoirdupois system, used in the US and UK for everyday commerce, defines 1 pound = 16 ounces = 453.59237 grams exactly. The stone (14 pounds) is still used for body weight in the UK. Specialty units serve specific industries: the carat (0.2 grams) is the universal standard for gemstone weight; the troy ounce (31.1035 g) is the standard for precious metals trading; and the grain (64.79891 mg) is used in ballistics and pharmacy. Three different 'tons' cause frequent confusion: the metric ton (1,000 kg), the US short ton (2,000 lbs / 907.2 kg), and the British long ton (2,240 lbs / 1,016 kg). This converter handles all three. Weight measurement conventions vary worldwide. The United States uses pounds and ounces for nearly everything — groceries, body weight, shipping. The United Kingdom uses a hybrid system: stone and pounds for body weight, but kilograms and grams in shops (by law since 2000). Continental Europe, East Asia, and most of the world use kilograms and grams exclusively. China uses the 斤 (jīn, 1 jīn = 500 g) as an informal everyday unit alongside kilograms. In the precious metals and gemstone industries, troy ounces and carats are universal regardless of country. All conversions use the exact factors defined by NIST and are calculated entirely in your browser — no data is transmitted to any server, keeping your measurements completely private. Need to convert other measurement types? Try our length converter for distance units, volume converter for liquid measurements, or temperature converter for °C, °F and Kelvin. ``` // Key weight conversion factors: // 1 kg = 1000 g // 1 lb = 453.59237 g (exact, by definition) // 1 oz = 28.349523125 g // 1 stone = 6350.29318 g (14 lbs) // 1 troy oz = 31.1034768 g // 1 carat = 0.2 g (exact) // 1 grain = 0.06479891 g // JavaScript conversion examples: const kgToLbs = (kg) => kg * 2.2046226218; const ozToGrams = (oz) => oz * 28.349523125; const stoneToKg = (st) => st * 6.35029318; console.log(kgToLbs(70)); // 154.324 console.log(ozToGrams(8)); // 226.796 console.log(stoneToKg(11)); // 69.8532 ``` #### FAQ **Q: How many pounds are in a kilogram?** A: One kilogram equals approximately 2.20462 pounds. For quick mental math, multiply kilograms by 2.2 — this gives a result accurate to within 0.2%. For example, 80 kg × 2.2 = 176 lbs (exact: 176.37 lbs). The precise NIST conversion factor is 1 kg = 2.2046226218 lbs. To convert pounds back to kilograms, divide by 2.2046 or multiply by 0.4536. **Q: How many grams are in an ounce?** A: One avoirdupois ounce equals approximately 28.3495 grams. For a quick estimate, use 28.35 grams per ounce. Common reference points: 1 oz = 28.35 g, 4 oz (quarter pound) = 113.4 g, 8 oz (half pound) = 226.8 g, 16 oz (one pound) = 453.6 g. Note that a troy ounce (used for precious metals) is heavier at 31.1035 grams. **Q: How many pounds are in a stone?** A: One stone equals exactly 14 pounds (6.35029 kg). The stone is commonly used in the UK and Ireland for expressing body weight. Common stone-to-pound conversions: 8 stone = 112 lbs, 10 stone = 140 lbs, 12 stone = 168 lbs, 14 stone = 196 lbs, 16 stone = 224 lbs. To convert stone to kilograms, multiply by 6.35029. **Q: What is the difference between a metric ton, a short ton, and a long ton?** A: A metric ton (tonne) = 1,000 kg = 2,204.6 lbs. A US short ton = 2,000 lbs = 907.2 kg. A British long ton = 2,240 lbs = 1,016 kg. The metric ton is used internationally, the short ton is standard in the US, and the long ton is used in British shipping. The differences are significant: a metric ton is about 10% heavier than a short ton, and a long ton is about 1.6% heavier than a metric ton. **Q: What is the difference between mass and weight?** A: Mass is the amount of matter in an object, measured in kilograms. Weight is the force of gravity on that mass, measured in newtons. On Earth's surface, a 1 kg mass has a weight of approximately 9.81 newtons. In everyday use, 'weight' and 'mass' are used interchangeably because we almost always measure on Earth. This converter handles mass units — the values are correct anywhere on Earth's surface, though technically your 'weight' varies slightly with altitude and latitude. **Q: What is the difference between a troy ounce and a regular (avoirdupois) ounce?** A: A troy ounce equals 31.1035 grams, while a standard avoirdupois ounce equals 28.3495 grams — the troy ounce is about 9.7% heavier. Troy ounces are exclusively used for precious metals (gold, silver, platinum, palladium). When a news report says 'gold is $2,000 per ounce,' it always means troy ounces. Confusing the two would cause a 9.7% pricing error. **Q: How can I quickly convert kg to lbs in my head?** A: The easiest mental math method: multiply by 2 and add 10%. For example, 75 kg: 75 × 2 = 150, plus 10% (15) = 165 lbs (exact: 165.35 lbs). This gives accuracy within 0.2%. Another approach: multiply by 11 and divide by 5, which gives the exact factor of 2.2. For going from lbs to kg, divide by 2.2 — or halve the number and subtract 10%. **Q: How accurate is this weight converter?** A: This converter uses the exact conversion factors defined by NIST (National Institute of Standards and Technology). All calculations use IEEE 754 double-precision floating-point arithmetic, providing at least 15 significant digits of precision. For everyday conversions, scientific calculations, and commercial transactions, the results are far more precise than any physical scale. The tool runs entirely in your browser with no rounding shortcuts. **Q: Is my data safe when using this weight converter?** A: Yes, completely. All conversions are performed locally in your browser using JavaScript. No data is sent to any server — there are no network requests, no cookies, and no analytics on your input. The conversion logic runs entirely on your device, meaning your values never leave your browser. You can verify this by disconnecting from the internet and using the tool — it works fully offline once the page has loaded. **Q: How many ounces are in a pound?** A: One pound contains exactly 16 avoirdupois ounces. This is an exact definition, not an approximation. Useful fractional references: 1/4 lb = 4 oz, 1/2 lb = 8 oz, 3/4 lb = 12 oz. Note that a troy pound (rarely used) contains only 12 troy ounces. When someone says 'pound' and 'ounce' without qualification, they mean the avoirdupois system used in everyday commerce. **Q: How many milligrams are in a gram?** A: 1 g = 1,000 mg exactly. This is a standard metric decimal relationship. Common references: one aspirin tablet = 325 mg, one vitamin C tablet = 500 mg, one caffeine capsule = 200 mg. The mg→g conversion is most frequently used in pharmaceutical dosages, nutrition labels, and laboratory measurements. **Q: How many grams are in a pound?** A: 1 lb = 453.59237 g (exact NIST definition). For quick estimates, use 454 g. Common references: 1/4 lb = 113.4 g (quarter-pounder burger patty), 1/2 lb = 226.8 g, 1 lb butter = 454 g (4 sticks). This conversion comes up frequently when adapting recipes between US and metric measurements. See also our volume converter for liquid ingredient conversions. **Q: What is a grain and where is it used?** A: 1 grain = 64.79891 mg = 0.0648 g. The grain is one of the oldest weight units still in active use, surviving in two specialized fields: pharmacy (aspirin was historically dosed in grains — 5 gr = 325 mg) and ballistics (bullet weights are measured in grains, e.g. a 9mm round = 115–147 gr). Try converting grains using the Specialty unit group above. **Q: How do I convert between 斤 (jīn) and kilograms?** A: 1 斤 (jīn, also called "catty") = 500 g = 0.5 kg. This is the most common everyday weight unit in mainland China, used for groceries, produce, and casual body weight references. 1 kg = 2 斤. Note: Southeast Asian catties differ (Malaysia: 1 catty = 604.79 g). This tool uses international standard units; for 斤 conversions, simply multiply the kg result by 2. **Q: What do common everyday objects weigh?** A: Weight reference points for building intuition: a paper clip ≈ 1 g, a US quarter coin ≈ 5.67 g, a medium egg ≈ 50 g, a smartphone ≈ 172 g, a liter of water = 1,000 g (1 kg), a bowling ball ≈ 6 kg (13 lbs), an average adult ≈ 70 kg (154 lbs). These anchors help you estimate whether a conversion result is reasonable. For size comparisons, our length converter covers 16 units of distance. --- ### Free Word Counter & Character Count Tool URL: https://go-tools.org/tools/word-counter Count words, characters, sentences, paragraphs, and reading time instantly. Real-time word counter with Twitter, meta description, and Instagram limit checks. Free, private, no signup. #### What Is a Word Counter? A word counter is a tool that takes a block of text and reports the metrics writers, editors, and publishers care about: how many words it contains, how many characters (with and without spaces), how many sentences and paragraphs, and how long it would take to read aloud or silently. Word counters are older than personal computers — typewriter editors counted by hand and later by typewriter-attached digital counters — but the browser-based, real-time word counter is the form most writers use today. The core unit, the word, sounds simple but isn't. English word counters tokenize on whitespace and hyphens-as-internal-punctuation: "don't" is one word, "state-of-the-art" is one word, "twenty-five" is one word. Numbers are usually counted as words (so "42" is one word) but stop-word filters in NLP contexts may exclude them from analysis. For Chinese, Japanese, and Korean text, the convention is one word per ideograph — a 500-character Chinese essay is a 500-word Chinese essay — because CJK doesn't use word-spaces and the smallest semantic unit is the character. Microsoft Word, Google Docs, native Chinese word-processors, and every serious bilingual counter follow this rule, and so does this tool. Beyond raw counts, modern word counters compute reading time and speaking time. The standard reading rate is 230 words per minute, the median silent-reading speed measured across decades of academic research on native-English readers (Brysbaert's 2019 meta-analysis). The standard speaking rate is 130 wpm, the rate that conference speakers, voiceover artists, and TED talks converge on — slow enough to be heard clearly, fast enough to feel natural. Blog platforms, news sites, and content management systems use these rates to display "x-minute read" indicators that set reader expectations. For digital publishing, character ceilings now matter more than word counts in many contexts. Twitter/X posts are capped at 280 characters. Google's meta description displays roughly 150-160 characters before truncation on desktop, fewer on mobile. Page title tags clip at about 60 characters in search results. SMS messages bill per 160-character segment. Instagram captions cap at 2,200 characters. A word counter that doesn't show these limits leaves you eyeballing the line — this one displays a live progress bar against each limit so you know when you've crossed a ceiling that affects display, deliverability, or ranking. Under the hood, a word counter is a few hundred lines of regex and string handling. The interesting engineering is in the edge cases: mixed CJK and Latin text, Unicode code-point counting versus UTF-16 code unit counting (emoji are surrogate pairs and would otherwise count as two), apostrophes inside contractions versus surrounding quoted speech, em-dash separators versus em-dash compounds, sentence terminators inside abbreviations. This tool's counting follows the conventions of Microsoft Word and Google Docs because those are the editors most people receiving your text will use to verify the count — agreement matters more than philosophical purity. All computation runs entirely in your browser — no text leaves the page, no signup is required, no logging. This matches the privacy expectations of journalists with source notes, lawyers with client drafts, marketers with unannounced campaigns, and anyone else who treats their work in progress as confidential. To go deeper into related text tooling, the Base64 encoder handles binary-to-text encoding, the URL encoder handles URL-safe text, and the MD5 hash generator handles fingerprinting — together they cover most non-format text manipulation a developer or content worker needs. ``` // What's actually being counted (simplified) function countWords(text) { // CJK: each ideograph is one word const cjk = text.match(/[\u4E00-\u9FFF\u3040-\u30FF\uAC00-\uD7AF]/g) || []; // Latin: word = letters/digits with optional internal hyphen or apostrophe const latin = text .replace(/[\u4E00-\u9FFF\u3040-\u30FF\uAC00-\uD7AF]/g, ' ') .match(/[A-Za-z0-9]+(?:[''-][A-Za-z0-9]+)*/g) || []; return cjk.length + latin.length; } // Reading time at 230 wpm function readingMinutes(words) { return Math.round((words / 230) * 60); // seconds } // Twitter limit check — raw character ceiling 280 function underTwitterLimit(text) { return [...text].length <= 280; // Unicode code points, not UTF-16 units } ``` #### FAQ **Q: What does this word counter do?** A: It counts every metric writers, editors, marketers, students, and developers care about — words, characters with and without spaces, sentences, paragraphs, and lines — in real time as you type or paste. It also computes reading time (230 wpm), speaking time (130 wpm), and compares your text against the character limits of Twitter/X, Instagram, LinkedIn, SMS, page title tags, and meta descriptions. A secondary analysis panel shows the top ten most frequent meaningful words (English stop-words filtered out), the longest single word, the average word length, and the average sentence length — the metrics that actually help you tighten prose. Everything runs 100% in your browser using JavaScript: your text is never uploaded, never logged, never stored, and no signup is required. **Q: How accurate is the word count compared to Microsoft Word and Google Docs?** A: The Latin word count matches Microsoft Word and Google Docs in the overwhelming majority of cases. All three tools tokenize on whitespace, treat hyphenated compounds (e.g., "state-of-the-art") as a single word, and split contractions ("don't" = 1 word). For mixed English-CJK text, this counter follows the same convention as Microsoft Word's Chinese/Japanese mode: each CJK ideograph counts as one word, and Latin tokens count individually. The handful of edge cases where counters diverge — em-dash compounds, em-dashes used as commas, numbers with decimals — affect <0.1% of typical text and produce off-by-one differences at most. For billable counts, copy your text into both this tool and your editor of choice once to confirm; you'll see the numbers agree. **Q: Is my text uploaded or stored anywhere?** A: No. All counting and analysis runs 100% client-side in your browser using JavaScript. Your text is never transmitted, never stored on any server, never logged, and never analyzed by humans or AI. This makes the tool safe for drafts containing client information, unannounced product names, internal memos, legal documents, journalist source notes, and any other confidential material. You can verify this in your browser's Network tab — typing in the textarea triggers zero network requests. The tool uses no cookies for the input text and no third-party analytics that would capture what you type. **Q: How is reading time calculated?** A: Reading time uses the adult silent-reading average of 230 words per minute, which is the median rate measured across 17 academic studies of native-English silent reading (Brysbaert 2019 meta-analysis). This is the rate most blog platforms, news sites, and "x-minute read" indicators converge on. Speaking time uses 130 words per minute, the standard rate for clear conference talks, voiceover, and TED-style delivery — slow enough for audiences to absorb, fast enough to feel natural. Both rates are conservative defaults: skim reading runs 400+ wpm, audiobook narration 150-180 wpm, and rapid auctioneer-style speech 250+ wpm. For specialized contexts, treat the displayed time as a baseline and adjust mentally. **Q: Does this work for Chinese, Japanese, Korean, and Arabic?** A: Yes. The counter handles all major scripts natively. For Chinese, Japanese, and Korean (CJK), each ideograph counts as one word — the same convention used by Microsoft Word, Google Docs, and native CJK word-processors. So a 500-character Chinese essay shows as 500 words, matching what your Chinese teacher or editor expects. For Arabic and other RTL scripts, the counter measures by whitespace-separated tokens and renders results respecting your input direction. Mixed-script text (English + Chinese, Arabic + English) is counted using both rules: CJK characters and Latin tokens are tallied separately and combined. The character count is always Unicode-code-point accurate — emoji, combining marks, and surrogate-pair characters each count once, not twice. **Q: Why is the Twitter limit 280 characters and how does this tool handle URLs?** A: Twitter/X enforces a 280-character ceiling on tweet text (doubled from the original 140 in 2017). This tool counts the raw character length of your text — what you'd see if you pasted into Twitter's compose box. Twitter automatically shortens URLs to a fixed 23 characters at publish time regardless of original length, so a 100-character URL in your draft still costs 23 once published. To check what Twitter will count, treat any URL as 23 characters: if your draft has one URL, the published length is (your raw count) − (URL length) + 23. The counter displays your raw count; the math for URL substitution is a manual step. For Twitter premium long-form posts (up to 25,000 characters), the 280-cap doesn't apply. **Q: What's the right meta description length for Google?** A: Aim for 150-160 characters. Google's meta description display on desktop typically truncates between 155 and 165 characters depending on the title and URL length of the snippet, with mobile clipping a few chars earlier. Below 120 characters Google often substitutes a longer auto-generated description from the page body — wasting your hand-crafted message. The sweet spot is 150-160: enough to use Google's full display width, short enough to survive mobile truncation. This counter's meta-description progress bar turns green between 120-160, amber 161-200, and red above 200. Note that Google sometimes truncates earlier than 155 if it can fit a better excerpt; the only way to fully control your snippet is to hand-write it under 155 chars. **Q: What counts as a sentence?** A: This counter treats a sentence as a run of text ending in a sentence terminator: period (.), question mark (?), exclamation mark (!), Chinese full stop (。), Japanese full stop (。), or Arabic question mark (؟). Multiple terminators in a row ("What?!") count as one sentence boundary. Sentences without a final terminator ("Hello world" with no period) still count as one. The counter intentionally doesn't apply heuristics for "Mr." or "U.S.A." — the rare false positives are noisier than the false negatives, and most published prose uses different abbreviation conventions. For a strict linguistic parse, use a dedicated NLP library; for everyday writing, the terminator-based count matches what teachers, editors, and word-processors report. **Q: How do I count words in a Word document or PDF?** A: Open the file, copy all the text (Ctrl/Cmd-A then Ctrl/Cmd-C), and paste into the counter's textarea above. The count appears instantly. For PDFs with multi-column layouts or table-heavy content, the copy may include extra spaces or interleaved column text — review the pasted text for obvious artifacts before trusting the count. For documents you can't open in a browser (scanned PDFs, image-only files), use OCR first (Adobe Acrobat, Google Drive OCR, or any free OCR tool), then paste the extracted text. This tool intentionally doesn't accept file uploads: keeping everything in the browser means your sensitive documents never leave your device. **Q: Why are some words excluded from the top frequency list?** A: The top frequency analysis filters out English stop-words — common function words like "the", "and", "is", "of", "that" that dominate any text but carry no editorial signal. The filtered list is the universal stop-word set used by most search engines and NLP libraries. The frequency analysis also skips words shorter than 2 characters and pure numbers. For non-English text, no stop-word filter is applied — you'll see the raw frequencies, which is still useful for catching repetition in any language. To get the unfiltered top words, mentally include the obvious function words from your language; the editorial value is in what comes after them. **Q: Does the counter support markdown or HTML?** A: The counter treats markdown and HTML as plain text — markdown syntax (`**bold**`, `[link](url)`, `# heading`) and HTML tags (``, ``) are counted as characters and tokenized as words. If you want to count just the rendered text (excluding markdown syntax or HTML tags), preview your markdown in a renderer (or open the HTML in a browser) and copy the rendered output before pasting. For most prose-with-light-formatting, the raw count is within 5% of the rendered count and good enough for tracking. For HTML-heavy content with lots of tags, the difference becomes significant — render first, then count. **Q: Is there a daily word count goal I should hit?** A: Nonfiction writers and bloggers typically aim for 500-1,500 words per day; novelists chasing NaNoWriMo target 1,667 words per day for a 50,000-word manuscript in November. Academic writers commonly set 250-500 words per day during dissertation phases — the slow-but-sustainable pace. Twitter threads, marketing copy, and shorter formats track total characters instead. The right target is the one you can sustain seven days a week without burning out; consistency beats peak velocity. This counter shows reading time alongside word count so you can also target by audience time: a 4-minute read is roughly 1,000 words, a 10-minute read is roughly 2,500. **Q: Why might my count differ from another online word counter?** A: Different counters handle edge cases differently: (1) Hyphenated compounds — most counters (including this one and Microsoft Word) treat "state-of-the-art" as one word; a minority split on hyphens and count four. (2) Em-dash separators — some counters split words on em-dashes, this one does not. (3) Numbers — some skip them entirely, this one counts them as words. (4) CJK text — many Western counters split CJK on whitespace only and undercount by 100x; this counter follows the Microsoft Word convention of one word per CJK character. (5) URLs — some counters strip URLs before counting, this one includes them as one token each. The Word/Google Docs convention is the de facto standard and what this tool follows; if a counter disagrees with both Word AND Google Docs, it's the outlier. --- ### XML Formatter URL: https://go-tools.org/tools/xml-formatter Beautify, minify, and validate XML in-browser — nothing uploaded. Re-indents messy XML, reports well-formedness errors with line/column. Free, private, no signup. #### What is an XML Formatter and Why Use One? XML (Extensible Markup Language) is a text-based format for structured data, used everywhere from web services and configuration files to RSS feeds, SOAP APIs, office documents (DOCX, XLSX), SVG graphics, and Android layout files. Unlike JSON, XML supports comments, namespaces, mixed content (text and elements interleaved), and document-type declarations — making it the format of choice for enterprise integration, document exchange, and anywhere structured data needs to coexist with human-readable markup. XML in the wild is often badly indented or completely minified — API responses arrive on a single line, config files accumulate inconsistent indentation, and generated XML from serializers adds no whitespace at all. An XML formatter takes that messy input and re-indents it into a clean, hierarchical structure where every level of nesting is visually clear. This is essential for code review, debugging, documentation, and understanding unfamiliar XML schemas. **What this tool does differently from a plain text editor:** **1. Well-formedness validation with precise error location.** The formatter uses the browser's DOMParser (the same engine that parses HTML and SVG) to parse the XML. If the document is not well-formed — mismatched tags, unclosed elements, unescaped characters, or multiple root elements — the parser reports the exact line and column number where it failed. This is far faster than reading raw XML looking for where a tag was accidentally left open. **2. Lossless formatting.** The formatter preserves comments, processing instructions, CDATA sections, namespace declarations, attribute order, and all text content exactly. It only adjusts the whitespace between element tags. You can safely format any XML you care about — nothing meaningful will change. **3. Minification for production use.** The minifier strips all insignificant inter-element whitespace, producing the smallest valid XML representation. This is the right preprocessing step before storing XML in a database column, inserting it as a string into JSON, or transmitting it over a byte-counted channel. **4. 100% browser-based privacy.** Healthcare XML (HL7, FHIR), financial data, SOAP payloads with credentials, and internal configuration files are all common XML payloads that contain sensitive data. This tool never uploads anything — all processing runs in your browser's JavaScript engine. See our companion tools if you need to convert rather than format: XML to JSON Converter for converting XML to JSON, and JSON to XML Converter for the reverse direction. ```
Wireless Headphones 79.99 Wireless Headphones 79.99 - with a closing tag like
- . The result is ready to paste straight into a template, a component, a Storybook story, or a CMS rich-text editor without the find-and-replace step you would otherwise do on plain text. If you want the text without markup, leave Format on Plain text. Markdown format is also available for blank-line-separated paragraphs and hyphen-prefixed lists, and JSON format returns an array of strings for fixtures and mocks.
**Q: Can I generate an exact number of words, characters, or paragraphs?**
A: Yes. The Generate control selects the unit and the Amount control sets the exact quantity. Choose Words to get a precise word count, Paragraphs or Sentences for those units, List items for short fragments, or Bytes to fill an exact byte budget — useful for testing a database column width or a character-limited field. Because the Lorem vocabulary is pure ASCII, the byte count equals the character count, so 255 bytes is also 255 characters. Each unit has a generous ceiling (for example 1,000 words or 10,000 bytes) to keep one click from generating an unmanageable wall of text; the live counter under the output confirms the word, character, and paragraph totals of what you generated.
**Q: What is the difference between Lorem Ipsum, dummy text, and placeholder text?**
A: In everyday use the three terms are interchangeable — they all mean filler content that stands in for real copy while a design is built. "Lorem Ipsum" names the specific pseudo-Latin text that became the industry standard; "placeholder text" and "dummy text" are the generic categories that Lorem Ipsum belongs to. Placeholder text can also include other styles, such as themed variants (Bacon Ipsum, Hipster Ipsum) or simple repeated strings, but Lorem Ipsum remains the default because its neutral, language-agnostic look doesn't tempt reviewers to read it. When a designer asks for "some dummy text," Lorem Ipsum is almost always what they mean.
**Q: Will using Lorem Ipsum hurt my SEO or get my page penalized?**
A: Lorem Ipsum is fine during development but should never ship to a live, indexable page. It carries no penalty by itself, but if Google crawls a published page full of placeholder text, that page has no real content to rank and may be treated as thin or unfinished — wasting crawl budget and confusing users who land on it. The risk is accidental publication: a staging template, a forgotten footer, or a CMS default that goes live with Lorem still in it. Use the generator freely while building, then replace every block with real copy before launch, and search-and-replace "Lorem ipsum" across your project as a final pre-deploy check.
**Q: Does the generated text repeat, and is it the same every time?**
A: Each generation draws words at random from the classic Lorem vocabulary, so two blocks at the same settings will differ — that is what the Regenerate button is for when you want several distinct samples of the same length. With the "Start with Lorem ipsum…" toggle on, every block begins with the same canonical first line and then diverges. The randomness is purely in your browser and is not cryptographic; it exists only to make the filler look natural, with varied sentence lengths and an occasional comma, rather than mechanically repetitive.
**Q: Can I use the generated Lorem Ipsum in commercial projects?**
A: Yes, without restriction. Lorem Ipsum is not copyrighted — it is mangled Latin in the public domain — and the text this tool produces comes with no license, attribution, or usage terms. Paste it into client work, commercial products, paid templates, or anything else. The only caveat is the universal one: it is placeholder text, so replace it with real content before the project ships to real users. Nobody owns Lorem Ipsum, and nothing about generating it here creates an obligation to anyone.
---
### Markdown to HTML Converter
URL: https://go-tools.org/tools/markdown-to-html
Convert Markdown to HTML in your browser — full GitHub Flavored Markdown, live preview, syntax highlighting. Export an HTML fragment, full document, or email-safe inline-styled HTML. 100% private, no upload.
#### What is Markdown to HTML Conversion?
Markdown to HTML conversion turns a plain-text document written in Markdown — with `#` for headings, `**bold**`, `- ` for lists, and `[text](url)` for links — into the HTML that browsers, content management systems, and email clients actually display. Markdown is designed to be readable as-is and easy to write, but a browser does not understand `# Heading`; it understands <h1>Heading</h1>. Conversion bridges that gap.
Under the hood, a Markdown processor first parses your source into an abstract syntax tree (AST) — a structured representation where a heading, a paragraph, a list, and a code block are distinct nodes with their content and attributes. It then serialises that tree to HTML, emitting the correct tags and nesting. Working through an AST, rather than swapping text with regular expressions, is what lets the converter handle nested lists, tables, and embedded HTML correctly and predictably. The two recognised grammars are CommonMark, the precise standard, and GitHub Flavored Markdown (GFM), which extends it with tables, task lists, strikethrough, and autolinks.
The reason you convert at all is that almost every publishing destination wants HTML, not Markdown. A static-site generator, a CMS rich-text field, an email template, and a browser tab all render HTML. So the typical workflow is to write in comfortable Markdown — a README, documentation, a blog draft, notes — and convert to HTML at the point of publishing. This tool does that conversion locally and shows a live preview, so you see the rendered result and can copy the exact HTML in the shape you need: a fragment, a full page, or email-ready inline-styled markup.
The reverse operation — HTML back to Markdown — is equally useful when you are migrating existing web content into a Markdown-based system. For that, switch to the HTML → Markdown tab or open the dedicated HTML to Markdown converter.
```
Markdown in:
# Release Notes
We shipped **tables** and `code`:
| Feature | Status |
| ------- | ------ |
| GFM | Done |
- [x] Parse to an AST
- [ ] Profit
HTML out:
```
**Small JavaScript Files**
```html
```
## Base64 Variants
### Standard Base64 (RFC 4648)
- Uses `+` and `/` as the last two characters
- Uses `=` for padding
- Safe for most applications
### URL-Safe Base64 (RFC 4648 Section 5)
- Replaces `+` with `-`
- Replaces `/` with `_`
- May omit padding (`=`)
- Safe for URLs and filenames
### Comparison Example
```
Standard: "??>" → Pz8+
URL-Safe: "??>" → Pz8-
```
## Practical Code Examples
### JavaScript Implementation
```javascript
// Encoding
function encodeBase64(str) {
return btoa(unescape(encodeURIComponent(str)));
}
// Decoding
function decodeBase64(str) {
return decodeURIComponent(escape(atob(str)));
}
// Usage
const original = "Hello, World!";
const encoded = encodeBase64(original);
const decoded = decodeBase64(encoded);
console.log(`Original: ${original}`);
console.log(`Encoded: ${encoded}`);
console.log(`Decoded: ${decoded}`);
```
### Python Implementation
```python
import base64
# Encoding
def encode_base64(data):
if isinstance(data, str):
data = data.encode('utf-8')
return base64.b64encode(data).decode('ascii')
# Decoding
def decode_base64(encoded_data):
return base64.b64decode(encoded_data).decode('utf-8')
# Usage
original = "Hello, World!"
encoded = encode_base64(original)
decoded = decode_base64(encoded)
print(f"Original: {original}")
print(f"Encoded: {encoded}")
print(f"Decoded: {decoded}")
```
## Real-World Applications
### Web API Authentication
Many APIs use Base64 for basic authentication:
```javascript
const username = "user";
const password = "pass";
const credentials = btoa(`${username}:${password}`);
fetch('/api/data', {
headers: {
'Authorization': `Basic ${credentials}`
}
});
```
### JSON Web Tokens (JWT)
JWTs use Base64URL encoding for their header and payload:
```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0...
```
### Image Embedding
Embedding small images directly in HTML:
```html
```
## Performance Considerations
### Size Increase
Base64 encoding increases data size by approximately **33%**:
- 3 bytes of binary data → 4 bytes of Base64 text
- Overhead ratio: 4/3 = 1.33
### When to Use Base64
**Good for:**
- Small files (< 10KB)
- Reducing HTTP requests
- Embedding in CSS/HTML
- Text-based protocols
**Avoid for:**
- Large files
- Frequently changing content
- When binary transfer is available
- Performance-critical applications
### Caching Implications
- Base64 data URLs can't be cached separately
- Changes to embedded data require cache invalidation
- Consider external files for frequently updated content
## Best Practices
### 1. Choose the Right Variant
- Use standard Base64 for general purposes
- Use URL-safe Base64 for URLs and filenames
- Consider omitting padding when safe
### 2. Optimize for Performance
- Keep embedded data small (< 10KB)
- Use external files for large or frequently changing content
- Consider gzip compression for Base64 text
### 3. Security Considerations
- Base64 is encoding, **not encryption**
- Don't use Base64 to hide sensitive data
- Validate decoded data before use
### 4. Debugging Tips
- Use online tools for quick encoding/decoding
- Check for proper padding
- Verify character set compatibility
- When debugging config files that contain Base64 values, a [JSON5/JSONC-aware formatter](/blog/json5-jsonc-formatting-guide) can help you inspect them without stripping comments
## Try It Yourself
*Encode and decode Base64 instantly with our [Base64 Encoder/Decoder](/tools/base64-decode-encode) — supports UTF-8, URL-safe variants, and real-time conversion. 100% in your browser.*
## Frequently Asked Questions
### Does Base64 encoding provide any security?
No — Base64 is an encoding scheme, not encryption. Anyone can decode Base64 data without a key. It is designed for safe data transport, not confidentiality. Never use Base64 to "protect" sensitive information like passwords or API keys. For security, use proper encryption algorithms like AES-256 or TLS for data in transit.
### Why does Base64 increase data size by about 33%?
Base64 represents every 3 bytes of binary data as 4 ASCII characters. This 3-to-4 ratio means the output is always approximately 4/3 (133%) of the input size — a 33% increase. This overhead is the trade-off for being able to safely transmit binary data through text-only channels like email or JSON.
### What is the difference between standard Base64 and URL-safe Base64?
Standard Base64 uses `+` and `/` characters, which have special meanings in URLs. URL-safe Base64 (RFC 4648) replaces them with `-` and `_`, making the output safe for use in URLs, query parameters, and filenames without additional [percent-encoding](/tools/url-decoder-encoder). Most modern APIs prefer URL-safe Base64 for tokens and identifiers.
### When should I use Base64 Data URLs instead of regular image files?
Use Data URLs for small images under 2-4KB, like icons and simple logos, to eliminate an HTTP request. For larger images, regular files with proper caching are more efficient — Data URLs cannot be cached independently, increase HTML size by 33%, and must be re-downloaded with every page load.
### Can I use Base64 to encode non-ASCII text like Chinese or emoji?
Yes, but you must first convert the text to bytes using a character encoding like UTF-8, then Base64-encode those bytes. When decoding, reverse the process: Base64-decode to bytes, then interpret the bytes as UTF-8 text. Most modern libraries handle this automatically, but always specify UTF-8 explicitly to avoid encoding errors.
## Conclusion
Base64 encoding is a fundamental technology that bridges the gap between binary data and text-based systems. From its origins in email attachments to modern web applications, Base64 continues to be an essential tool for developers.
**Key takeaways:**
- Base64 converts binary data to safe ASCII text
- It's essential for email attachments and data URLs
- Choose the right variant for your use case
- Consider performance implications for large data
- Remember: it's encoding, not encryption
---
### Image to Base64 & Data URIs: When to Inline Images (2026)
URL: https://go-tools.org/blog/base64-images-data-uri-inline-guide
Should you convert an image to Base64? See when data URIs help, the 33% size cost, CSS/HTML inlining, caching tradeoffs, and when a normal image file wins.
When you convert an **image to Base64**, you get a **data URI**: a string like `data:image/png;base64,iVBORw0KGgo…` that you can paste straight into an HTML `src` or a CSS `url()`. The browser decodes it on the spot and shows the picture with no separate download. No file to host, no extra request.
So should you do it? Here is the short rule. Inline an image as Base64 when it is small (under about 2 KB), rarely changes, and you want to skip one HTTP request. Think tiny icons and logos. For everything else, keep it as a normal image file: large images, anything reused across pages, anything you want the browser to cache. The catch is that Base64 makes a file about 33% larger, and once that text is embedded in your HTML or CSS it can no longer be cached on its own.
If you want the exact numbers for a specific file, the [Image to Base64 converter](/tools/image-to-base64) does the encoding in your browser and shows the precise size increase, so you can decide with real data instead of a rule of thumb. This guide covers what that data URI actually is, the math behind the size tax, a decision matrix for when inlining pays off, and the cases where a plain file wins.
## What "image to Base64" actually produces: the data URI
Converting an image to Base64 does not give you a file. It gives you one long string that follows the data URI format defined in RFC 2397 (see [MDN's `data:` URL reference](https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Schemes/data) for the full spec). The string has three parts:
```
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
└──┬─┘ └───┬───┘ └─┬──┘ └─────────┬──────────┘
data: MIME type marker the encoded image bytes
```
The MIME type tells the browser what kind of image it is decoding. The common ones for images are `image/png`, `image/jpeg`, `image/gif`, `image/webp`, `image/svg+xml`, and `image/x-icon` for favicons. The `;base64,` marker says the payload that follows is Base64 rather than plain text. Everything after the comma is the image, re-expressed as printable ASCII.
That last part matters for privacy. The conversion runs entirely in your browser through the `FileReader` API's `readAsDataURL`, so nothing is uploaded to a server. You can drop a pre-launch screenshot or unreleased artwork into the tool and watch the Network tab stay empty. For the mechanics of how raw bytes become that ASCII string, [understanding Base64](/blog/understanding-base64) covers the encoding from the ground up, and the [complete Base64 guide](/blog/base64-complete-guide) extends the same data-URL idea to fonts, PDFs, and other file types.
### A real example: a 68-byte transparent PNG
Here is the smallest practical case, a 1×1 transparent PNG, 68 bytes on disk, written out as a complete data URI:
```
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==
```
Paste that into a browser address bar and you will see (well, not see, since it is transparent) a valid image render with zero network activity. Notice the trailing `==`: that is padding, which we will get to. This is also exactly what text Base64 looks like, just applied to image bytes instead of text. If you only need to encode or decode plain text strings, the [Base64 encode/decode](/tools/base64-decode-encode) tool handles that case.
## The 33% size tax (and why it compounds)
Base64 works in fixed groups: every 3 bytes of binary become 4 ASCII characters. Four-thirds is roughly 1.33, which is where the +33% figure comes from. Add a byte or two of padding plus the `data:image/png;base64,` prefix and the overhead is slightly higher for tiny files. A concrete example: a 9 KB PNG becomes about 12 KB of text.
Why exactly 3-to-4? Base64 uses a 64-character alphabet: `A`–`Z`, `a`–`z`, `0`–`9`, plus `+` and `/`. Sixty-four symbols is 6 bits of information per character, while binary bytes are 8 bits each. The lowest common multiple of 6 and 8 is 24 bits, which is 3 bytes or 4 Base64 characters, so the encoder works through the image 24 bits at a time. When the image length is not a clean multiple of 3, one or two `=` characters pad the final group. That math is fixed; no encoder setting shrinks the 33%.
That 33% is the visible cost. The hidden cost is that it compounds, and this is the part most "just inline it" advice skips:
- **The image is re-downloaded whenever the containing file changes.** An external `logo.png` is its own resource. Inline it into `styles.css`, and now any edit to that stylesheet, even a one-line color tweak, invalidates the cache for the image too. Visitors re-download the picture they already had.
- **It cannot be cached independently.** A normal image file is fetched once and reused across every page and every visit. An inlined data URI is part of the document, so it ships again on every page that embeds it and on every cache miss of that document.
- **CSS is render-blocking.** The browser will not paint until it has the CSS. Stuff a large data URI into a stylesheet and you have made a render-blocking resource bigger, delaying first paint for the whole page.
### Does gzip or brotli cancel the 33% out?
Partly, not fully. Base64 text is repetitive enough that gzip and brotli compress it well, clawing back a good chunk of the inflation over the wire. But two things remain true. First, the compressed Base64 is usually still a little larger than the compressed original binary, because you have handed the compressor a less efficient starting point. Second, and this is the part that bites, compression does nothing about caching or render-blocking. A smaller-over-the-wire data URI is still re-downloaded with its host file and still cannot be cached on its own.
So compressing the bytes is not the same as removing the cost of inlining them. If the distinction between minifying, gzipping, and brotli is fuzzy, the [code minification guide](/blog/code-minification-guide-css-js-html) lays out how those layers stack, and why squeezing the bytes never fixes the caching problem that inlining creates.
## When to use a Base64 image (the decision matrix)
The whole decision comes down to a handful of factors. Here they are side by side:
| Factor | Lean toward inlining (Base64) | Lean toward a normal file |
|--------|-------------------------------|---------------------------|
| **Size** | Under ~2 KB (green) | Over ~10 KB (red); 2–10 KB is a judgment call (amber) |
| **Reuse** | One page, a place or two | Repeated across many pages |
| **Change frequency** | Almost never changes | Edited often |
| **Context** | HTML email, self-contained widget or bookmarklet, JSON/API payload, a critical above-the-fold icon worth one saved request | Content images, shared cacheable assets |
Those size thresholds are not arbitrary. They mirror the traffic-light badge built into the [Image to Base64 converter](/tools/image-to-base64): green under 2 KB, amber up to 10 KB, red above. The tool reads your actual file and tells you which bucket it lands in.
### A simple rule of thumb
If you remember one line, make it this: **under ~2 KB and used in only one or two places, inlining usually pays off; over ~10 KB or reused across pages, a normal cached file almost always wins.** The 2–10 KB middle is where you weigh the saved request against the lost cache for your specific situation.
### Good fits in detail
A few cases where Base64 genuinely earns its keep:
- **HTML email.** Many email clients block externally hosted images by default for privacy, which breaks any layout that depends on a remote logo. A small inlined data URI renders immediately with no server fetch. Keep these to logos and icons; never inline a photograph into an email.
- **Self-contained widgets and bookmarklets.** A bookmarklet or an embeddable widget has to work with zero external dependencies. Inlining its icons keeps everything in a single droppable file.
- **JSON and API payloads.** Shipping a thumbnail inside a JSON document or a config file is sometimes the cleanest option: one round trip, one object, no second request to wire up.
- **A critical above-the-fold icon.** When a tiny logo is part of your Largest Contentful Paint and you want to shave one request off the critical path, inlining can help. Emphasis on *tiny*.
One pattern ties these together: in each case the asset travels *with* something else and would otherwise need its own delivery channel. An email cannot rely on your CDN, a bookmarklet has no second file to fetch, and a JSON response arrives as a single payload. So the alternative to inlining here is not a cached file but a missing image, which changes the calculus entirely. The useful question for a Base64 fit is not only whether the asset is small, but whether a separate file is even an option in the first place.
## When NOT to inline: caching, lazy loading, and Core Web Vitals
The flip side is longer, because inlining quietly disables several things the browser does well.
**You lose independent caching.** This stings most for returning visitors. A normal image sits in their cache after the first visit and loads instantly forever after. An inlined image has no independent cache entry; it rides along with the document every single time, so a repeat visitor pays the byte cost again and again.
**You lose lazy loading.** The `loading="lazy"` attribute lets the browser defer images that are below the fold until the user scrolls near them. A data URI is parsed and "downloaded" the instant the HTML is read, so there is nothing to defer. Inline a dozen below-the-fold images and you have forced all of them into the initial load.
**You enlarge render-blocking resources.** As noted earlier, a data URI inside CSS bloats a resource that blocks first paint. The bigger that stylesheet, the longer the page sits blank.
**Decoding is more expensive on mobile.** A data URI is Base64-decoded every time its document loads, and on low-end phones that extra CPU work adds up. Worse, the bytes never land in the browser's disk cache, so a heavy inlined image is re-decoded on each visit instead of being cached and decoded once like a normal file.
There is also a historical reason this advice has shifted. The original case for inlining, made loudly in the HTTP/1.1 era, was request reduction: each connection could fetch one resource at a time, so a page with 40 small icons paid 40 round trips. HTTP/2 changed that by multiplexing many requests over a single connection, which made extra small files cheap. The big payoff of inlining, fewer requests, mostly evaporated, while the costs stayed: lost caching, no lazy loading, bigger render-blocking files. If you read older articles enthusiastic about Base64 sprites, weigh them against the protocol your site actually runs on today.
### The Core Web Vitals angle
Inlining cuts both ways on LCP ([Largest Contentful Paint](https://web.dev/articles/lcp)). For a small, above-the-fold image that *is* the LCP element, removing a request can nudge LCP earlier. But inline a large image and you do the opposite: you delay the document or stylesheet it lives in, pushing LCP later for the whole page. The size threshold decides which way it goes.
For CLS (Cumulative Layout Shift), inlining changes nothing about the core rule: an image still needs explicit `width` and `height` (or an aspect-ratio box) so the browser can reserve space before it renders. A data URI without dimensions shifts layout exactly like a remote image without dimensions.
A better lever than inlining is usually shrinking the source. Compressing an image before you encode it makes both the file and any resulting data URI smaller. The [browser vs Node image compression guide](/blog/image-compression-browser-vs-node) covers how to do that client-side or in a build step, and [WebP vs AVIF vs JPEG](/blog/webp-vs-avif-vs-jpeg-image-format-guide) helps you pick a format that is small to begin with.
## How to inline images in HTML, CSS, Markdown, and JSON
Once you have a data URI, here is how it drops into each context. These are the four ready-to-paste snippets the [Image to Base64 converter](/tools/image-to-base64) generates for you.
**HTML**: paste the URI into any `src`:
```html
```
**CSS**: wrap it in `url()` for a `background-image` (this is the canonical base64 image in CSS pattern):
```css
.icon {
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");
}
```
**Markdown**: a self-contained image link for READMEs, GitHub issues, and notebooks where you cannot host a file:
```markdown
```
**JSON**: an embedded asset inside an API or config payload:
```json
{ "icon": "data:image/png;base64,iVBORw0KGgo…" }
```
All four work anywhere a URL is accepted: `img src`, CSS `background`, `mask-image`, even a favicon ``. Every modern browser supports the `data:` scheme.
### Generating these quickly
Building these by hand is error-prone: one wrong MIME type or a stray line break and the image silently fails to render. Drop your file into the [Image to Base64 converter](/tools/image-to-base64) and it produces all four snippets with their own copy buttons, plus the exact size increase so you know up front whether the asset belongs inline at all.
## SVG: the special case where Base64 usually loses
SVG breaks the usual logic, because SVG is text, not binary. Base64 exists to make binary data text-safe, but SVG is already XML text. Encoding it as Base64 just inflates a string that did not need encoding, and makes it unreadable in the process. So for SVG specifically, Base64 is almost always the wrong choice.
Compare three ways to inline the same icon:
```css
/* 1. Base64 data URI — adds the 33% tax to text that didn't need it */
.a { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…"); }
/* 2. URL-encoded data URI — percent-encode a handful of characters, no 33% tax */
.b { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'…%3C/svg%3E"); }
/* 3. Inline