simpletool.io Browse tools

Category: Free Tools

  • HTML Formatter: Beautify HTML with Prettier [2026]

    HTML Formatter: Beautify HTML with Prettier [2026]

    TL;DR: An HTML formatter (or “HTML beautifier”) takes minified, copied, or messy HTML and reformats it with consistent indentation, line wrapping, and attribute alignment. Use it on copied HTML you need to read or edit, AI-generated markup, or scraped pages. Our free HTML formatter uses Prettier 3 in your browser with full support for HTML5, Vue, Svelte, Angular, and Handlebars templates.

    Reading minified HTML is like reading a one-line essay — every tag and attribute is jammed together with no visual structure. Try to debug a layout issue or insert a new element and you spend more time finding your place than fixing the bug. A formatter restores the structure: each block-level element on its own line, nested elements indented, long attribute lists wrapped, and closing tags aligned with their opens.

    Our HTML formatter runs Prettier 3 in your browser. It auto-detects HTML5, Vue single-file components, Svelte, Astro, Angular, and Handlebars templates. Configurable: indent width, attribute-per-line wrap threshold, void-element style (<br /> vs <br>), and whether to wrap long lines. Paste any size, get clean output, copy or download.

    Prettier HTML options that matter

    Option Default When to change
    printWidth 80 100–120 if you have many attributes per element
    tabWidth 2 4 only if matching legacy code
    htmlWhitespaceSensitivity “css” “strict” if rendering depends on inline whitespace
    singleAttributePerLine false true for very wide attribute lists
    bracketSameLine false true to keep > at end of last attribute line
    endOfLine “lf” “crlf” only for Windows-only repos

    The whitespace-sensitivity setting (the option you’ll actually want to think about)

    HTML treats whitespace inconsistently. Inside a <p>, multiple spaces collapse to one. Inside a <pre>, every space is preserved. Between two inline elements (<span>a</span> <span>b</span>), the space between affects layout. Prettier’s htmlWhitespaceSensitivity option controls how aggressively the formatter rearranges whitespace:

    • “css” (default): respect CSS display defaults. Block-level elements get their own lines; inline elements stay on the same line where whitespace would matter. Best for most modern pages.
    • “strict”: never break a line where doing so would add or remove whitespace that affects rendering. Safest but produces longer lines.
    • “ignore”: format aggressively, ignoring the impact on rendering. Use only if you control the CSS and know your inline elements have white-space rules that override the default.

    Most pages format cleanly with the default. If you see layout shifts after formatting, switch to “strict” and reformat.

    How to format HTML in your browser

    1. Open the HTML formatter
    2. Paste your HTML or drop in a .html file
    3. Pick the parser (auto-detect usually works): html, vue, angular, handlebars, svelte
    4. Adjust print width and tab width to match your project
    5. Click Format — output appears with syntax highlighting
    6. Copy or download

    Templating-language support

    Prettier handles plain HTML, but real codebases often have templating syntax mixed in. Prettier 3 supports:

    • Vue: single-file components (.vue) with <template>, <script>, <style> blocks formatted independently.
    • Svelte: .svelte files including {#if} / {#each} blocks and reactive declarations.
    • Angular: *ngIf, *ngFor, and binding syntax ([prop], (event)) preserved.
    • Handlebars / Mustache: {{…}} and {{#each}} blocks indented like HTML elements.
    • Astro: via the prettier-plugin-astro plugin.

    For JSX (React), use the JavaScript Formatter instead — JSX lives in JS files and the JS parser handles both.

    Common gotchas

    • Whitespace inside <pre> and <textarea> is preserved. Prettier doesn’t touch their content. If yours looks wrong, the issue was already in your source.
    • Self-closing void elements: Prettier 3 outputs <br> (HTML5 default) not <br /> (XHTML). To force XHTML style, post-process or use a different tool — there’s no built-in option in Prettier 3.
    • Comments above tags get attached to them. Prettier may move comments slightly to keep them tied to the right element. Usually fine; occasionally surprising.
    • Custom Web Components are formatted like regular HTML elements. A <my-button> with attributes wraps the same way <button> does. No special handling needed.
    • Don’t format AI-generated HTML and ship it without checking. AI tools sometimes produce <div>…<span>…</div> with mismatched tags; the formatter happily produces beautifully indented broken HTML. Validate with the W3C validator after formatting.
    • Inline event handlers stay inline. Inline on* attributes (on​click, on​load) aren’t reformatted. Use external script tags for anything non-trivial.

    When NOT to use a browser HTML formatter

    For a real codebase, install Prettier locally (npm i -D prettier), commit a .prettierrc, and configure your editor to format on save. That eliminates formatting drift between developers. Use this browser tool for one-off snippets, copied HTML from a CMS or AI assistant, scraped markup you need to inspect, and pages built without a build pipeline. Don’t run the formatter on minified production HTML and re-deploy — keep source and minified output as separate artefacts.

    Frequently asked questions

    What’s the difference between an HTML formatter and a beautifier?

    Same thing, different name. “Formatter” is the modern term (Prettier, dprint); “beautifier” is older (jsbeautify, HTML Tidy). Both reformat messy or minified markup into readable, indented output.

    Can I format Vue, Svelte, or Astro components?

    Yes. Prettier 3 handles Vue single-file components, Svelte files, Angular templates, and Astro components natively. Auto-detection picks the parser from file extension; you can override manually for paste-mode input.

    Will formatting change how my page renders?

    With the default htmlWhitespaceSensitivity: "css", no — Prettier respects CSS display rules and only adds whitespace where it doesn’t affect rendering. Edge cases involving custom white-space CSS may need htmlWhitespaceSensitivity: "strict" to be safe.

    Can I unformat (minify) HTML with this tool?

    No — formatting and minifying are opposite operations. For minification, use the HTML Minifier. Format while editing; minify before deploying.

    Is my HTML uploaded?

    No. Prettier runs in your browser via WebAssembly. Pasted markup never reaches our servers — useful for proprietary or pre-release pages.

    Can I save my Prettier config?

    Yes. Settings persist in your browser’s localStorage between sessions. There’s also a “Copy as .prettierrc” button that exports your settings as JSON ready to drop into a project root.

    Related tools and guides

     

  • Make PDF Look Scanned: Browser-Only Converter [2026]

    Make PDF Look Scanned: Browser-Only Converter [2026]

    TL;DR: A “scanned PDF converter” makes a clean digital PDF look like it came out of a real scanner — adds skew (slight rotation), paper grain, faded ink, edge shadows, and downsamples to 96–150 DPI. Used for forms that demand “scanned” submissions, courtesy submissions where a printout-and-rescan would be the official process, and for visual consistency in workflows that mix scanned and digital documents. Our free scanned PDF converter runs entirely in your browser using pdf-lib + canvas filters.

    The “please submit as a scanned PDF” requirement is one of the small absurdities of digital paperwork. A perfectly valid digital signature is rejected by an HR system that still parses scanned forms only. A government portal expects an “ink-on-paper” feel even though the form was filled in Word. Some e-discovery systems flag clean PDFs as suspicious because they assume real submissions go through a copier. The fix: take your clean digital PDF and run it through filters that mimic the artefacts of a real scan — grain, skew, faded edges, slightly off-white paper.

    Our scanned PDF converter applies five effects in combination: skew (random ±2° rotation per page), grain (paper texture noise), ink fade (slight contrast reduction), edge shadow (vignetting from the scanner glass), and resolution downsample (rasterise to 150 DPI). The result passes most “looks scanned” detectors without any of the security concerns of uploading sensitive forms to an unknown server. This guide covers each effect, when to use this for legitimate workflows, and the legal grey areas to avoid.

    The 5 effects and what each fixes

    Effect Tells it fixes Default value
    Skew Perfectly aligned page edges ±1.5° rotation per page
    Paper grain Pixel-perfect text and uniform background 8% noise, low contrast
    Ink fade Pure black text, 100% saturation Reduce contrast 12%, RGB shift to #1a1610
    Edge shadow Razor-sharp page boundaries 12px gradient at edges, 30% opacity
    Resolution Vector-perfect text rendering Rasterise to 150 DPI
    Paper tint Pure white background #fdfaf2 (off-white)
    JPG compression Sharp PNG-grade quality JPG quality 80, slight blocking

    Three intensity presets

    Most users don’t need to tune individual sliders. The presets cover 95% of cases:

    • Light: subtle grain and skew, retains text crispness. For legitimate forms where the scanned look is a courtesy.
    • Medium (default): noticeable grain, ink fade, edge shadow. The “honest scan” preset.
    • Heavy: aggressive aging — strong grain, brown paper tint, more skew. For documents you want to look old or photocopied many times.

    Pick a preset, preview the first page, adjust if needed.

    How to make a PDF look scanned

    1. Open the scanned PDF converter
    2. Drop your PDF in
    3. Pick a preset: Light, Medium, or Heavy
    4. Adjust skew amount, grain intensity, paper tint, and resolution if needed
    5. Click Convert. Each page is rasterised, processed, and re-embedded
    6. Download the converted PDF — typically 2–4× the original file size due to raster pages

    Legitimate uses (and the line you shouldn’t cross)

    Legitimate:

    • Forms that demand a “scanned” submission for visual consistency (HR forms, some legal templates, some government portals)
    • Submitting a digital fill of a form designed to be printed-and-scanned
    • Visual consistency in mixed scanned/digital archives
    • Mock-ups for UI design (e.g., showing what a scanned doc looks like in a doc-management UI)
    • Educational examples of OCR pre-processing

    Don’t:

    • Forge documents — making a fake invoice “look scanned” to deceive someone is fraud, regardless of whether you used Photoshop or this tool
    • Pass off a generated document as having gone through a paper original — for any document that requires a wet-ink signature, use one
    • Strip metadata to hide the original source from a fraud investigation
    • Manipulate evidence — adding “scanned” artifacts to a document submitted in legal proceedings is evidence tampering

    The tool is for honest workflows. If your use case requires the recipient to believe the file went through a paper-and-scanner pipeline that it didn’t, you’re in fraud territory.

    Common gotchas

    • File size grows. Rasterising vector pages to images (even at 150 DPI) typically 2–4× the original file size. A 1 MB digital PDF becomes 2–4 MB scanned-look output. Run through a PDF compressor after if size matters.
    • Text becomes uncopyable. The output is image-based — selecting text returns nothing. Most workflows treat that as a feature (real scans are also image-based until OCR). If you need selectable text, don’t run this conversion.
    • Search engines and accessibility tools can’t read it. A converted PDF has no machine-readable text — which is fine for forms but bad for archival. Keep the digital original.
    • Skew direction. Use random ±skew per page, not constant ±skew. A constant tilt looks like a misaligned scanner, not a stack of slightly-misfed pages.
    • Paper colour. Pure white (#FFFFFF) is the giveaway — real scans land on slightly off-white because of paper colour, ambient light, or scanner sensor calibration. Even at “Light” preset we tint to #fdfaf2.
    • Line art. CAD drawings and line-art-heavy documents can look damaged after grain + downsample. Test before processing technical drawings.

    When NOT to use this tool

    For documents that require legal authenticity (contracts, medical records, court filings), skip the conversion — submit the original PDF if possible, or scan a printed copy of the wet-signed version. For OCR or text extraction, the conversion makes things worse, not better — keep the digital original. For batch processing (100s of files at scanned-look output), install pdf-lib + sharp locally and script the conversion. For sensitive material where even browser processing is too risky, use offline software like ImageMagick on an air-gapped machine.

    Frequently asked questions

    Why would I want to make a PDF look scanned?

    Forms that demand “scanned” submissions for visual consistency, government portals that flag clean PDFs, HR systems that only accept scan-style files, and visual consistency across archives that mix scanned and digital documents. Always for honest workflows — fabricating documents to deceive someone is fraud regardless of the tool.

    Will the converted PDF still have selectable text?

    No. The conversion rasterises each page, so the output is image-based. Selecting text returns nothing. Most workflows that demand “scanned” PDFs expect this — real scans are also image-based until OCR is applied. If you need selectable text, don’t run this conversion.

    How much does the file size grow?

    Typically 2–4× the original. A 1 MB digital PDF becomes 2–4 MB after raster conversion at 150 DPI. Run the output through a PDF compressor if size matters — a moderate compression brings it back close to the original size while keeping the scanned look.

    Is this legal?

    The tool itself is legal everywhere. The output’s legality depends on use. Submitting a converted file to a workflow that demands “scanned” format for visual consistency is fine. Using it to forge documents (fake invoices, fake official records) is fraud regardless of the tool.

    Is my PDF uploaded?

    No. The converter runs in your browser using pdf-lib + canvas. The file loads into a blob URL and never leaves your tab. You can verify in the Network tab — zero outbound requests after upload.

    Can I undo the conversion?

    No — once rasterised, the original vector text is gone. Always keep your digital original in a separate file. The converted file is a one-way derivative, not a wrapper around the original.

    Related tools and guides

     

  • Lorem Ipsum Generator: Placeholder Text in Seconds [2026]

    Lorem Ipsum Generator: Placeholder Text in Seconds [2026]

    TL;DR: A lorem ipsum generator produces placeholder text — sentences and paragraphs of fake-Latin filler — for design mockups, layout prototyping, and content-shaped void filling. Our free lorem ipsum generator outputs by paragraphs, sentences, or word count, with optional HTML markup (<p> wrappers) for direct paste into a CMS, and the canonical “lorem ipsum dolor sit amet” opening or randomised text.

    Lorem ipsum has been the design industry’s placeholder text since the 1500s, when an unknown printer adapted a 45 BC philosophy treatise by Cicero — De finibus bonorum et malorum — into nonsense Latin to demonstrate typesetting fonts without distracting readers with real content. Five centuries later, every CMS, design tool, and front-end mockup still leans on it. The reason it stuck: real content distracts. When you’re showing a client a layout, you want them looking at the layout, not reading the words.

    Our lorem ipsum generator outputs by paragraph count, sentence count, or word count, with options for HTML wrapping, randomised vs. canonical opening, and instant copy. This guide explains the right and wrong uses of placeholder text, the alternatives worth considering, and the gotchas that lead to “lorem ipsum” accidentally shipping to production (it has happened — embarrassingly — at multiple Fortune 500 companies).

    What lorem ipsum actually says (and why it doesn’t matter)

    The canonical first sentence — “Lorem ipsum dolor sit amet, consectetur adipiscing elit” — is a corruption of Cicero’s “Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit”. The original translates roughly to “There is no one who loves pain itself, who seeks after it and wants to have it, simply because it is pain”. The placeholder version is gibberish — words have been chopped, jumbled, and elongated into nonsense.

    That nonsense is the point. Lorem ipsum’s job is to occupy visual space without drawing reader attention. Real content immediately triggers comprehension instincts; the reader starts thinking about the message. Pseudo-Latin defeats that instinct — your brain registers “text-shaped” without engaging with meaning. Designers can evaluate typography, hierarchy, line-length, and rhythm without the user (or the client) getting distracted by what the text says.

    Five legitimate uses of lorem ipsum

    • Wireframes and mockups. Before content is written, designers fill body areas with lorem ipsum to show structure. The whole point of a wireframe is to communicate layout independently of content.
    • Stress-testing typography. Real content rarely fills the worst-case scenarios — extra-long paragraphs, missing line breaks, weird character combinations. Lorem ipsum stretches across the layout reliably for QA.
    • CMS template development. Building a WordPress theme or design system component? Lorem ipsum demonstrates how the template handles arbitrary text without exposing real client data during development.
    • Print-design proofing. Magazine layouts, brochures, and editorial designs test column flow with lorem ipsum before final copy lands.
    • Email template testing. Email clients render unpredictably; testing with lorem ipsum across Gmail/Outlook/Apple Mail catches breakage before real campaigns send.

    How to use the browser lorem ipsum generator

    1. Open the lorem ipsum generator
    2. Choose unit: paragraphs, sentences, or words
    3. Set quantity (1-50 paragraphs, 1-100 sentences, 1-1000 words)
    4. Toggle “Start with Lorem ipsum dolor sit amet…” for the canonical opening, or leave off for randomised
    5. Toggle “Wrap in HTML” to get <p> tags around each paragraph (paste-ready for CMS visual editors that don’t auto-wrap)
    6. Click Copy to grab the generated text, or Generate again for a fresh sample

    The output is generated client-side by selecting from a curated word list and assembling sentences with realistic Latin-like punctuation distribution. Nothing transmits to a server.

    Lorem ipsum alternatives — when filler text needs personality

    Alternative Vibe When to use
    Bacon Ipsum Meat-themed (bacon, prosciutto, t-bone) Restaurant menus, food brands
    Hipster Ipsum Brooklyn-flavour adjective stew Trendy startup mockups
    Corporate Ipsum Synergize-leverage-ROI buzzwords B2B SaaS pitch decks
    Cupcake Ipsum Sugar/dessert words Bakery, candy, kid-targeted designs
    Real content Actual draft copy Anything past initial wireframe — content shapes design

    Themed alternatives are fun for early-stage mocks but should never be left in production. They draw attention to themselves the way real lorem ipsum doesn’t, and clients tend to comment on them rather than the design.

    The “lorem ipsum shipped to production” hall of fame

    Lorem ipsum makes it to production websites surprisingly often. Search “lorem ipsum site:nytimes.com” or any major brand domain on Google and you’ll find archived examples. Common scenarios:

    • Form-field placeholders — the “Enter your email” placeholder in a signup form gets replaced with “Lorem ipsum” and ships.
    • Image alt text — accessibility audits surface lorem ipsum alt attributes on production marketing images.
    • Empty CMS fields — a category page renders lorem ipsum because the editor never wrote real introductory text.
    • Email signatures — corporate email templates with placeholder paragraphs still in them, sending to real customers.
    • Mobile app onboarding screens — the third onboarding step’s body text never got written, lorem ipsum ships in the app.

    Every team that has shipped lorem ipsum to production swears they have a “before-launch checklist” now. Search-and-replace for “lorem ipsum” across your codebase before deploys.

    Generating lorem ipsum in code

    Node.js (lorem-ipsum npm package):

    import { LoremIpsum } from "lorem-ipsum";

const lorem = new LoremIpsum({
  sentencesPerParagraph: { max: 8, min: 4 },
  wordsPerSentence: { max: 16, min: 4 },
});

console.log(lorem.generateParagraphs(3));

    Python (lorem package):

    import lorem
print(lorem.paragraph())   # one paragraph
print(lorem.text())         # multiple paragraphs

    VS Code shortcut (Emmet):

    // In any HTML file, type "lorem" + Tab → 30 words of lorem ipsum
// Or specify count: "lorem50" → 50 words

// Wrap in elements:
// p*3>lorem  → 3 paragraphs each containing lorem ipsum

    Common mistakes with lorem ipsum

    • Using it past wireframe stage. Once visual design is approved, lorem ipsum should be replaced with real content. Designs that look great with placeholder text often break with real content (longer headlines, shorter body copy, missing data).
    • Forgetting it in CSS comments or hidden fields. “Lorem ipsum” sometimes lurks in CSS comments or HTML attributes that don’t render but show up in search results or developer-tool inspections.
    • Letting it indicate quality. A product page with three perfectly-typeset paragraphs of lorem ipsum looks like a finished product to your eye. Real content of the same length might be three short bullet points and an FAQ. Test designs against realistic content shapes, not idealised paragraphs.
    • Using English-language lorem ipsum. Some “lorem ipsum” alternatives are actually English nonsense words. They’re harder to ignore — your brain auto-parses them — defeating the purpose. Stick with Latin-style for layout work.

    When NOT to use lorem ipsum

    • For final-stage user testing. Test with realistic content. Users react differently to “Lorem ipsum dolor” than to “Track your medication, set reminders, share with your doctor”.
    • For accessibility testing. Lorem ipsum’s punctuation and word-length distribution doesn’t match real screen-reader experience. Test with real content for accessibility.
    • For SEO content audits. Lorem ipsum has zero topical relevance and zero search potential. Don’t analyse search performance against placeholder text.
    • For client previews on a launched site. Lorem ipsum on a live URL looks unprofessional. Use a staging environment.

    Frequently asked questions

    Does lorem ipsum text mean anything?

    The canonical lorem ipsum is a corruption of Cicero’s De finibus bonorum et malorum from 45 BC, scrambled in the 1500s by an anonymous printer. Words were chopped, reordered, and altered into pronounceable nonsense. There’s no meaningful translation — that’s intentional. The text exists to occupy visual space without engaging the reader’s comprehension.

    How much lorem ipsum should I generate for a typical mockup?

    For body content, 50-100 words per paragraph and 2-4 paragraphs per section. For headlines, 5-12 words. For meta descriptions, ~25 words (matches Google’s snippet length). The goal is matching realistic content shape, not maximum filler.

    Will Google penalise pages containing lorem ipsum?

    Not directly — Google doesn’t single out lorem ipsum for penalty. But pages with lorem ipsum almost universally have other quality issues (thin content, no real value, draft state) that Google’s algorithm penalises. Lorem ipsum is a symptom, not a cause. Search Console may surface “lorem ipsum dolor” as a query you’re ranking for, which is embarrassing but not dangerous.

    Can I use lorem ipsum commercially?

    Yes. Lorem ipsum is in the public domain — Cicero died over 2000 years ago, and the modern corruption has been used continuously since the 1500s. No copyright applies. Use it freely in any commercial design work or product.

    What’s the best length for lorem ipsum in a wireframe?

    Match real content. If your real article will be 800 words, generate 800 words. If your hero subhead will be 8-12 words, generate 8-12. Designs that look balanced with the wrong filler length break when real content arrives. Always test against realistic content shape.

    Is the lorem ipsum generator generated locally?

    Yes. The text is assembled in your browser using a curated word list. No requests are made to any server. Verify in DevTools Network tab — there are no API calls when you click Generate.

    Related tools and guides

     

  • JSON Tree Viewer Online: Validate, Format, Search [2026]

    JSON Tree Viewer Online: Validate, Format, Search [2026]

    TL;DR: A JSON tree viewer takes raw JSON text and renders it as an interactive collapsible tree — easier to read, navigate, and validate than a flat text dump. Our free JSON tree viewer online handles validation, pretty-printing, search, and collapse/expand. Runs entirely in your browser; supports JSON files up to 100MB. No upload, no signup.

    Every developer has had this moment: a 5,000-line JSON response from an API, dropped into a text editor, immediately overwhelming. Where’s the user object? Is the date field a string or a timestamp? Is that array of 200 items really 200, or did somebody slip a null in at position 42? A JSON tree viewer makes the file navigable — click to collapse arrays you’re not interested in, click to expand the ones you are, search for specific keys.

    Our JSON tree viewer validates and renders any JSON document in your browser — no upload, no rate limits, no analytics on what you paste. This guide explains the syntactic gotchas that produce parse errors, the difference between a tree viewer and a formatter, the security implications of pasting JSON containing tokens, and the API workflows where a tree viewer earns its place.

    What a JSON tree viewer does that a text editor doesn’t

    • Validates as you paste. Invalid JSON shows a clear error with line/column. No more “Unexpected token at position 1247” cryptic messages — the viewer points at the exact problem.
    • Auto-indents and pretty-prints. Minified JSON ({"a":1,"b":[2,3]}) becomes readable tree structure with consistent 2-space indents.
    • Collapses and expands sections. Click the disclosure triangle to collapse an array of 1,000 items into [1000]. Drill into specific paths without scrolling through irrelevant data.
    • Search across keys and values. Find every occurrence of “user_id” or “null” or any specific value. Often the fastest way to verify whether a deep field exists.
    • Type indication. Strings show as one colour, numbers another, booleans another, null another. At a glance, you can spot when a number got serialised as a string by mistake.
    • Path tracking. Hover over any value to see its full JSONPath ($.users[3].profile.email). Useful when constructing JSONPath queries for tools like jq, JMESPath, or your API’s filter syntax.

    Common JSON syntax errors and their causes

    Error Cause Fix
    Trailing comma [1, 2, 3,] or {"a":1,} Strict JSON disallows trailing commas. Remove the last comma.
    Single quotes {'name': 'value'} JSON requires double quotes on all strings and keys.
    Unquoted keys {name: "value"} JavaScript object syntax, not JSON. Quote all keys.
    JavaScript comments // or /* */ Standard JSON disallows comments. Use JSON5 or strip before parsing.
    NaN, Infinity, undefined Non-finite numbers JSON only allows finite numbers and null. Convert before serialising.
    Unescaped backslashes in strings "path": "C:\Users\..." Backslashes need escaping: "C:\\\\Users\\\\..."
    BOM at start of file UTF-8 BOM (EF BB BF) bytes Some parsers reject. Save without BOM.

    The viewer’s error messages point at the exact line and character where parsing failed, with the offending character highlighted. For unhelpful errors like “Unexpected end of input”, scroll to the bottom of the file — usually a missing closing brace or bracket.

    How to use the browser JSON tree viewer

    1. Open the JSON tree viewer
    2. Paste JSON into the input panel, or drop a .json file
    3. The tree renders on the right, collapsible at every level
    4. Click any node’s disclosure triangle to expand / collapse
    5. Use the search box at the top to find specific keys or values
    6. Hover over a value to see its JSONPath at the bottom of the panel
    7. Click “Format” to pretty-print the source, or “Minify” to compress
    8. Click “Copy” to copy the formatted JSON, or “Download” for a file

    The viewer handles JSON files up to ~100MB practically — beyond that, browser memory becomes the bottleneck.

    Why pasting API JSON into a third-party site is risky

    The reason browser-based tools matter for JSON specifically: the JSON people inspect most often contains exactly the data attackers want.

    • API responses include tokens. JWT auth tokens, API keys, OAuth refresh tokens — common in JSON payloads. Pasting into a hosted tool means handing those credentials to a third party.
    • Database dumps include PII. Customer names, emails, addresses, sometimes payment info — all common in JSON exports from production systems.
    • Internal config files include infrastructure details. AWS bucket names, IP ranges, internal hostnames — useful for reconnaissance if leaked.
    • Webhook payloads include audit data. Events containing user actions, timestamps, IP addresses.

    Our viewer runs entirely in your browser via JavaScript’s built-in JSON.parse. Your JSON never leaves your device. Verify by opening DevTools’ Network tab — there are no requests when you paste, format, or search. For JSON containing real production credentials, this is the only safe workflow.

    JSON tooling beyond the viewer — jq, JMESPath, and friends

    jq (CLI — the standard for JSON processing in shell scripts):

    # Pretty-print
cat data.json | jq .

# Extract a nested field
curl -s api.example.com/user | jq '.profile.email'

# Filter an array
cat users.json | jq '.[] | select(.verified == true) | .name'

# Convert JSON to CSV
cat data.json | jq -r '[.id, .name, .email] | @csv'

    JMESPath (used by AWS CLI and many APIs):

    aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId, State.Name, Tags[?Key==`Name`]|[0].Value]' \
  --output table

    JavaScript / Python deep extraction:

    // JavaScript optional chaining
const email = data?.user?.profile?.email ?? "(missing)";

// Python with deep get
def get(obj, *keys, default=None):
    for k in keys:
        if not isinstance(obj, dict) or k not in obj: return default
        obj = obj[k]
    return obj

email = get(data, "user", "profile", "email", default="(missing)")

    The browser tree viewer is for exploration; jq and JMESPath are for repeatable extraction. Use both — the viewer to understand the shape, jq to script the transformation.

    Common gotchas when working with JSON

    • Numbers losing precision. JSON’s number type is a 64-bit float. Numbers above 2^53 (about 9 quadrillion) lose precision when parsed. APIs returning long IDs as numbers (9223372036854775807) often look correct in JSON but get rounded by JavaScript’s parser. Best practice: APIs should serialise IDs as strings.
    • Date formatting. JSON has no native date type. Most APIs use ISO 8601 strings ("2026-04-23T14:32:00Z") but some use Unix timestamps as numbers (1745418720). The tree viewer shows them as their literal type — interpret in context.
    • Unicode in keys vs values. JSON allows Unicode in string values but historically required ASCII for keys. Modern parsers accept Unicode keys; older systems sometimes reject them.
    • Order preservation. JSON objects are technically unordered. JavaScript engines preserve insertion order for non-integer keys, but don’t rely on it for canonicality. If order matters, use an array of [key, value] pairs.

    When NOT to use a browser JSON tree viewer

    • For JSON files larger than 100MB. Browser RAM becomes the bottleneck. Use jq, ijson (Python), or a streaming JSON parser at the command line.
    • For real-time monitoring of JSON streams. Use ndjson (newline-delimited JSON) processing in your terminal, not a one-shot tree viewer.
    • For automated parsing. The viewer is for human inspection. Use jq, ijson, or your language’s JSON library for any scripted workflow.
    • For JSON5 / JSONC files. Standard JSON parsers reject comments and trailing commas. Use a JSON5-aware parser or strip non-standard syntax first.

    Frequently asked questions

    Will the JSON tree viewer handle invalid JSON?

    Yes — and that’s its primary value when JSON is broken. Invalid JSON shows a clear error message pointing at the line and column of the parse failure, with the offending character highlighted. Once you fix the issue, paste again and it renders correctly.

    What’s the maximum JSON file size?

    Practically ~100MB before browser memory becomes the bottleneck. The native JSON.parse method handles large files efficiently, but the tree-rendering UI slows down significantly above that. For larger JSON, use jq or ijson at the command line.

    Is my JSON sent anywhere?

    No. The viewer uses JavaScript’s native JSON.parse in your browser. The JSON you paste, the formatted output, and any searches all stay on your device. Verify by opening DevTools’ Network tab — there are no requests during use.

    Does the viewer handle JSON5 / JSONC?

    Standard JSON only. JSON5 (with comments and trailing commas) and JSONC (JSON with comments) are not supported by JavaScript’s native parser. Strip the non-standard syntax first, or use a JSON5-aware tool like json5 on npm.

    Can I export the tree as a hierarchy diagram?

    Not directly. The tree is rendered as collapsible HTML, which works well in browsers but not as a printable diagram. For visual diagrams, copy a representative snippet of the JSON, format it, and screenshot the formatted output. For full hierarchy diagrams, use specialised tools like JSONCrack.

    What’s the difference between a JSON viewer and a JSON formatter?

    A formatter pretty-prints JSON as readable text — adds indentation and line breaks but stays as a flat text view. A tree viewer shows JSON as an interactive hierarchy with expand/collapse, search, and path tracking. Most JSON tree viewers (including ours) include both — formatter for output, tree for interactive exploration.

    Related tools and guides

     

  • HTML Entity Decoder & Encoder: Escape HTML Safely [2026]

    HTML Entity Decoder & Encoder: Escape HTML Safely [2026]

    TL;DR: An HTML entity decoder turns escape sequences like &lt;, &amp;, &#039;, and &quot; back into the original characters (<, &, ', "). The encoder does the reverse — replacing unsafe HTML characters with named or numeric entities so the browser renders them as text instead of parsing them as markup. Use our free HTML encoder/decoder to escape user input safely or recover content from a feed that arrived double-encoded.

    Every web developer eventually pastes a string from a CMS export, an XML feed, or a database column and sees &amp;quot;Hello&amp;quot; where they expected "Hello". That’s an HTML entity round-trip gone wrong. HTML escapes a small set of characters that have structural meaning — <, >, &, ", ' — into named entities (&lt;, &gt;, &amp;, &quot;, &#039;) so they appear as text rather than triggering tag parsing. Get the encoding right and your user-supplied content is rendered safely; get it wrong and you have either visible escape sequences or, worse, an XSS vulnerability.

    Our HTML encoder and decoder handles named entities (&eacute;, &copy;, &ndash;), numeric decimal entities (&#233;, &#169;), numeric hex entities (&#x00E9;), and the full HTML5 named-entity table (2,231 named entities). It runs entirely in your browser. This guide covers when to encode, the difference between named and numeric entities, double-encoding, and the XSS edge cases naive encoders miss.

    The 5 characters you must always escape — and 2 you should

    Character Named entity Numeric (decimal) Required in
    & &amp; &#38; Everywhere — encode first or you’ll double-encode
    < &lt; &#60; Text content — prevents tag injection
    > &gt; &#62; Text content (defensive — not strictly required)
    " &quot; &#34; Inside double-quoted attributes
    ' &#39; &#39; Inside single-quoted attributes (note: &apos; is HTML5 only)
    © &copy; &#169; Optional — only if not serving as UTF-8
    — (em dash) &mdash; &#8212; Optional — only if not serving as UTF-8

    Named vs numeric vs hex entities

    You’ll see HTML entities in three forms in the wild. Named entities like &copy; are readable but only work for the ~2,231 characters that have an HTML5 name. Numeric decimal entities like &#169; reference the Unicode code point in base 10. Hex entities like &#xA9; reference the same code point in base 16. All three render identically.

    • Use named when readability matters and the character has a well-known name (&nbsp;, &copy;, &trade;).
    • Use numeric when you want maximum compatibility — every Unicode code point can be expressed numerically; not every character has a named entity.
    • Use hex when copying from a Unicode reference where code points are listed in hex (U+00A9 → &#xA9;). Hex is also more compact for high-codepoint characters.

    Important: &apos; for the single quote is HTML5-only. In HTML4 and XHTML 1.0 it’s not in the named-entity table — emails and old browsers may render it literally as &apos;. Use &#39; for maximum compatibility, especially in HTML emails.

    How to encode or decode HTML in your browser

    1. Open the HTML encoder/decoder
    2. Paste the string in the input box
    3. Pick Encode (text → entities) or Decode (entities → text)
    4. For encode, optionally toggle Numeric only to skip named entities (safer for emails and legacy clients)
    5. Click Copy to copy the output, or Decode again if the result still contains entity sequences (double-encoded data)

    XSS-safe context-aware encoding (what naive encoders miss)

    HTML entity encoding is not a one-size-fits-all defence against XSS. The right escape depends on where in the page you’re inserting user data. The OWASP-recommended split:

    • HTML body context: escape <, >, &. Inserting user text between tags.
    • HTML attribute context: additionally escape " (or ' if your attribute uses single quotes). Always quote your attributes; unquoted attributes are an injection vector.
    • JavaScript context: HTML entity escaping does not protect you here. Use JavaScript string escaping (< for <) or, better, JSON.stringify.
    • CSS context: use CSS hex escapes (\3C for <), not HTML entities.
    • URL context: use URL encoding (%3C for <), not HTML entities.

    Our encoder produces HTML-context escapes by default with an option for attribute-context (more aggressive). For JavaScript or URL contexts, use the URL encoder or escape inside JSON.

    Common gotchas

    • Encode the ampersand first. If you encode < to &lt; first, then encode & to &amp;, you’ll double-encode and end up with &amp;lt;. Always replace & first, then the rest.
    • Double-encoded feeds. RSS feeds, MailChimp exports, and CMS APIs sometimes encode their own escape sequences again. &amp;amp; means the original was & encoded twice. Decode twice to recover.
    • Non-breaking space looks like a space but isn’t. &nbsp; (U+00A0) is invisible but breaks string-equality checks. If your string compare fails despite identical-looking text, replace nbsp with regular space first.
    • Internet Explorer recognised non-standard named entities. Avoid &apos; in HTML emails for IE/Outlook compatibility — use &#39;.
    • Numeric entities work for any code point. Need a thumbs-up emoji? &#128077; works everywhere; the named entity does not exist.
    • UTF-8 makes most named entities unnecessary. If your page is served as charset=utf-8 (which it should be in 2026), you only need to escape &, <, >, ", and '. Don’t encode ©, —, é — just write them directly.

    When NOT to use this tool

    For server-side templating, use your framework’s auto-escaping: React ({value} escapes by default), Vue, Handlebars, Jinja2, Thymeleaf, ERB, Liquid all escape HTML automatically. Only reach for an external encoder when you have a stuck string from a feed, log, or copy-paste of an export. For programmatic encoding in client-side JS, element.textContent = userInput is safer than building an HTML string and encoding it — the DOM API never confuses content with markup.

    Frequently asked questions

    What’s the difference between HTML entity encoding and URL encoding?

    Different places, different rules. HTML entity encoding makes characters safe to include inside an HTML document (& → &amp;). URL encoding (percent-encoding) makes characters safe to put inside a URL (& → %26). They are not interchangeable. Use HTML for HTML, URL for URLs.

    Why does my page show &amp;quot; instead of “?

    Double-encoding. The string was encoded once (" → &quot;), then encoded again, so & became &amp; and the result is &amp;quot;. Decode twice to recover. Long-term fix: encode at exactly one layer of your stack — typically right before output, never during storage.

    Does my framework already escape HTML?

    Probably yes, if you use template syntax like React’s {value}, Vue’s {{ value }}, Jinja2’s {{ value }}, or Handlebars’s {{ value }}. All escape by default. The dangerous variants — React’s dangerouslySetInnerHTML, Vue’s v-html, Jinja2’s |safe — bypass escaping. Audit those carefully.

    Should I use named or numeric entities?

    Numeric is more universal. Named entities (&copy;) are readable but only ~2,231 characters have HTML5 names. Numeric entities (&#169;) work for every Unicode code point. For HTML emails, prefer numeric — old email clients may not recognise newer named entities like &apos;.

    Is my data uploaded?

    No. The encoder/decoder runs in your browser via JavaScript. Pasted content is never sent to our servers, which makes it safe for decoding tokens, signed cookies, or potentially sensitive feed data.

    How many named HTML entities exist?

    HTML5 defines 2,231 named character references. They cover the named entities from HTML4 plus many more — including math symbols, arrows, and Greek letters. Our decoder handles all of them. The full list is in the WHATWG HTML spec.

    Related tools and guides

     

  • Image Color Picker Tool: Sample HEX, RGB & HSL [2026]

    Image Color Picker Tool: Sample HEX, RGB & HSL [2026]

    TL;DR: An image color picker tool samples the exact colour of any pixel from an uploaded photo and converts it to HEX, RGB, HSL, and CMYK. Designers use it to extract brand palettes, match a website’s accent to a hero photo, or steal the perfect blue from a sunset shot. Our browser-based image color picker processes the photo locally — no upload, no signup, click anywhere on the image to sample.

    The fastest way to find a colour you can describe but can’t name: photograph it (or screenshot it) and run an image color picker over it. Brand designers do this with mood-board photos. Frontend developers do it when matching a CSS background to a hero image their team’s photographer captured. Print designers do it before specifying CMYK values for a poster run. The photo holds the colour information at full precision; an image color picker translates that into the format your CSS, design tool, or print spec actually uses.

    Our image color picker tool reads the photo via your browser’s canvas API and extracts the exact RGB values of any pixel you click. It outputs in HEX, RGB, HSL, HSV, and CMYK simultaneously, with one-click copy on each format. The photo never uploads — useful for proprietary brand work, NDA-protected mockups, or anything you’d rather keep off third-party servers.

    The five colour formats and when each is right

    Format Example Use for
    HEX #635BFF CSS, brand guidelines, design tools — the universal web colour notation
    RGB rgb(99, 91, 255) Programming (every image library uses RGB), some legacy CSS
    HSL hsl(244, 100%, 68%) Building palettes — easier to derive lighter/darker shades by adjusting one number
    HSV hsv(244, 64%, 100%) Photoshop and Affinity Photo’s default colour picker — useful for matching design files
    CMYK cmyk(61%, 64%, 0%, 0%) Print — magazine, brochure, business card. Different gamut from RGB; expect approximation

    Why HSL is the designer’s secret weapon. Once you have a colour in HSL, you can build an entire palette by changing only the lightness. hsl(244, 100%, 68%) with the lightness pushed to 90% becomes a soft tint suitable for a card background; pushed to 30% becomes a deep shade for hover states. RGB and HEX don’t expose this control as cleanly — adjusting them to a perceived lighter/darker version requires multiple channel changes that often shift the hue.

    The CMYK caveat. Computer screens use additive RGB; printers use subtractive CMYK. The two colour spaces don’t perfectly align — vivid screen blues, oranges, and greens often can’t be reproduced in print. The CMYK output from a screen-photo color picker is an approximation; for production print work, ask your printer for their colour-managed conversion (they’ll use ICC profiles to map RGB → CMYK accurately).

    Five common workflows for an image color picker

    • Brand palette extraction. Drop your company’s hero photo into the tool, click on the four or five distinctive colours. Save those as the starter palette for your design system.
    • Matching website accents to imagery. When a marketing photo dominates a landing page, the CTA buttons and section backgrounds look better when they pull from the photo’s palette. Sample from the photo first, then build the CSS.
    • Reproducing a competitor’s colour. Found a colour you like on someone else’s site or in a magazine? Screenshot, drop into the picker, copy the HEX. Faster than guessing and far more accurate than a paper colour wheel.
    • Print colour matching. Photograph a paint chip or fabric swatch under daylight, sample it, and use the result as the starting CMYK for a printed brochure. Calibrate against the actual print sample for accuracy.
    • Accessibility audits on photos. Sample the dominant colour of a photo behind text. Run the WCAG contrast check against your text colour. If it fails, you know exactly which photo region needs an overlay.

    How to use the browser image color picker

    1. Open the image color picker
    2. Drop your photo onto the dropzone, or click to pick from disk
    3. The image renders in a zoomable canvas. Use scroll-wheel or pinch to zoom in for pixel-precision sampling
    4. Click anywhere on the image to sample — the HEX, RGB, HSL, HSV, and CMYK values appear instantly with a swatch preview
    5. Click the copy icon next to any format to grab that exact value to your clipboard
    6. Sample additional pixels by clicking new locations — each sample stays in your history sidebar for easy comparison

    Everything happens client-side via the canvas getImageData API. The photo never uploads, the sampled colour never transmits.

    Sampling colours in code

    Browser JavaScript (canvas getImageData):

    const canvas = document.createElement("canvas");
const img = new Image();
img.crossOrigin = "anonymous";
img.onload = () => {
  canvas.width = img.naturalWidth;
  canvas.height = img.naturalHeight;
  const ctx = canvas.getContext("2d");
  ctx.drawImage(img, 0, 0);

  // Sample pixel at coordinates (x, y)
  const [r, g, b, a] = ctx.getImageData(x, y, 1, 1).data;
  const hex = "#" + [r, g, b].map(n => n.toString(16).padStart(2, "0")).join("");
  console.log(hex);
};
img.src = "/path/to/photo.jpg";

    Node.js (Sharp + raw pixel access):

    import sharp from "sharp";

const { data, info } = await sharp("photo.jpg")
  .raw()
  .toBuffer({ resolveWithObject: true });

const idx = (y * info.width + x) * info.channels;
const [r, g, b] = [data[idx], data[idx + 1], data[idx + 2]];
console.log(`rgb(${r}, ${g}, ${b})`);

    Python (Pillow):

    from PIL import Image

img = Image.open("photo.jpg")
r, g, b = img.getpixel((x, y))[:3]
print(f"#{r:02x}{g:02x}{b:02x}")

    The four mistakes that produce the wrong colour

    • Sampling JPEG artefact pixels. JPEG compression creates colour noise around hard edges. A pixel sampled at the boundary between a logo and its background often has a “halo” colour that doesn’t match either neighbour. Sample 10-20 pixels into the solid region.
    • Trusting screenshots over the source. If you screenshot a website to sample its CSS colour, your screen’s colour profile, your monitor’s calibration, and macOS/Windows’s gamma all shift the values. Use browser DevTools’ eyedropper directly on the live element instead.
    • Mixing up sRGB and Display P3. Modern Macs and iPhones photograph in Display P3 colour space, which encodes vivid colours that sRGB can’t reach. A picker that assumes sRGB on a P3 photo returns desaturated values. Most browser tools handle this automatically, but be aware when results look slightly off.
    • Sampling backlit or shadowed regions. A subject’s shirt looks bright pink in direct sun, dim pink in shade. The “real” colour exists somewhere in between — for brand work, photograph in even diffused light or sample multiple regions and average them.

    When NOT to use a single-pixel color picker

    • For palette extraction from complex photos. A single pixel doesn’t represent a photo’s overall colour story. Use a dominant-colour or palette-extractor tool that analyses the whole image. (We have one: the Image Color Extractor.)
    • For accessibility-grade colour matching. WCAG contrast calculations need precise colour values. A single sample can hit a JPEG artefact pixel; sample 20 and average for accuracy.
    • For print colour proofing. The CMYK approximation from a screen photo is rough. Order a printed proof or ask your printer for an ICC-managed conversion.
    • From low-resolution or heavily-compressed sources. A 200×200 thumbnail saved at JPEG quality 50 has bands of false colour everywhere. Source a higher-res copy if you need accurate colours.

    Frequently asked questions

    What’s the difference between an image color picker and a screen color picker?

    An image color picker samples colours from a static image you upload. A screen color picker (like Chrome DevTools’ eyedropper or macOS Digital Color Meter) samples colours directly from any pixel on your screen, including live web pages. For sampling a colour from a photo, image color picker. For sampling a CSS colour from a competitor’s live site, screen picker.

    Can I get the dominant colour of an entire image?

    Not from a single-pixel picker. Use our dedicated Image Color Extractor which analyses the whole image and returns the top 5-8 dominant colours plus a perceptual palette suitable for design systems.

    Why does my sampled HEX not match the colour I expected?

    Three common causes: (1) JPEG artefacts producing false colours near edges — sample further into solid regions; (2) your monitor’s calibration shifting how colours display; (3) the source photo using Display P3 colour space which encodes wider gamut than sRGB. For brand work, sample multiple pixels in the same region and use the median value.

    Is my photo uploaded when I use the picker?

    No. The browser reads the photo via the File API, draws it on a canvas, and reads pixel data from the canvas — all without making any network requests. Verify in DevTools’ Network tab. The photo and any sampled colours stay on your device.

    Can I sample colours from a website screenshot?

    Yes — drop the screenshot into the picker like any other image. For higher accuracy though, use Chrome DevTools or browser extensions that sample directly from the live page (avoiding screenshot compression). Both Chrome and Firefox have built-in eyedroppers in their colour pickers.

    Does the tool work on transparent PNGs?

    Yes. Transparent regions return alpha = 0 in the sample readout, with the underlying pixel colour shown for reference. If you click on a transparent pixel and want the colour you’d see (white if displayed on white), composite the image first or sample a non-transparent neighbour.

    Related tools and guides

     

  • Strong Random Password Generator: NIST-Aligned & Secure

    Strong Random Password Generator: NIST-Aligned & Secure

    TL;DR: A strong random password generator uses your browser’s Web Crypto API (crypto.getRandomValues) to produce passwords from genuine OS-level entropy, not predictable Math.random(). Aim for at least 80 bits of entropy — that’s roughly 16 mixed-case alphanumeric characters or a 6-word passphrase. Our free generator does both and shows you the entropy live, so you can see exactly how strong each output is.

    The fundamental rule of password security has changed quietly: NIST’s 2024 update (SP 800-63-4) prohibits forcing users to mix uppercase, lowercase, digits, and symbols. The reason is empirical. Forced complexity rules produced more predictable passwords, not stronger ones — users picked the same dozen tricks (capitalise the first letter, replace o with 0, add ! at the end) and attackers learned them years ago. The new guidance: length is what matters. A 16-character lowercase-only password has more entropy than an 8-character password using the full ASCII set.

    Our strong random password generator implements this guidance. It defaults to 20 characters with the full mixed-case alphanumeric+symbol pool, computes the entropy live, and runs entirely in your browser using the Web Crypto API — your password never travels to any server. This guide explains the math behind password strength, why Math.random() is dangerous, the three modes (random, pronounceable, passphrase) and when to use each, and the storage workflow that keeps strong passwords actually usable.

    Why password entropy matters more than complexity

    Password strength is measured in bits of entropy. A password with N bits of entropy means an attacker needs to try up to 2^N combinations to crack it by brute force. The math is simple: each character drawn at random from a pool of P characters contributes log₂(P) bits.

    Character pool Pool size Bits per character
    Lowercase only (a-z) 26 4.7
    Lower + upper (a-z, A-Z) 52 5.7
    Lower + upper + digits 62 5.95
    Lower + upper + digits + symbols ~94 6.55

    Multiply bits-per-character by length to get total entropy. The threshold to remember:

    • Under 40 bits: weak. Crackable in minutes-to-hours by a modern GPU farm against any common password hash.
    • 40-60 bits: moderate. Survives casual attacks but falls to determined attackers within days against fast hashes (MD5, SHA-256).
    • 60-80 bits: strong. Beyond practical brute force for any single attacker; survives most state-of-the-art GPU farms for years.
    • 80+ bits: excellent. Requires nation-state computational resources and decades of work. NIST’s recommended floor for high-security passwords.