Tag: Developer Tools

  • Code to Image Converter: Beautiful Code Screenshots [2026]

    Code to Image Converter: Beautiful Code Screenshots [2026]

    TL;DR: A code to image converter takes source code and renders it as a beautiful syntax-highlighted screenshot — perfect for sharing on Twitter/X, LinkedIn, blog posts, and tutorial slides. Our free code to image converter supports 100+ languages, multiple themes (Dracula, GitHub Light, Tokyo Night, etc.), window-chrome styling, and exports a high-resolution PNG. Browser-only, no upload.

    Plain code in a tweet looks awful. Twitter strips formatting, mobile viewers can’t read it, and you can’t paste a 30-line function as text without it becoming a mess. Code-to-image converters solve this — render your snippet with proper syntax highlighting, a stylised window chrome, and export as PNG. The result looks like a screenshot from your editor but is actually a fresh render at any resolution. Carbon (carbon.now.sh) popularised the format around 2017; the workflow is now standard for developer-influencer Twitter, conference slides, and tutorial blog posts.

    Our code to image converter supports 100+ programming languages via highlight.js, multiple popular themes, window controls (the three macOS dots), and adjustable padding/font size. Everything renders client-side; your code never transmits. This guide covers the language detection, theme choices that read well on social media, and the typography settings that produce clean exports.

    Why developer Twitter loves code screenshots

    • Visual punch in feeds. A code screenshot stops the scroll where plain text doesn’t. Tweets with code images get 4-6× the engagement of equivalent text-only tweets.
    • Twitter’s text rendering destroys formatting. Indentation collapses, monospaced characters render in proportional fonts, lines wrap unpredictably. An image preserves exactly what you wrote.
    • Multi-language demonstration. Showing the “before vs after” of a refactor, or comparing TypeScript vs JavaScript, requires consistent visual treatment that only screenshots provide.
    • Slides and tutorial content. Conference talks and YouTube tutorials need code that reads on a projected screen from 30 feet away. Screenshots at 4K resolution scale better than IDE captures.

    How to use the browser code-to-image converter

    1. Open the code to image converter
    2. Paste or type your code into the editor
    3. Pick a language (auto-detected for most common languages)
    4. Pick a theme — Dracula, Tokyo Night, GitHub Light, Atom One Dark, Monokai, and more
    5. Adjust padding, font size, line numbers, window chrome (macOS dots, title bar, none)
    6. Set background colour or gradient
    7. Click Export PNG. The result downloads at 2× retina resolution

    All rendering happens in your browser via canvas. Your code is never uploaded.

    Themes that read well on social media

    • Dracula: dark background with vibrant pink/purple/green syntax. Most popular on developer Twitter.
    • Tokyo Night: deep navy with muted neon highlights. Reads well in dense feeds.
    • GitHub Light: the official GitHub theme, conservative, professional. Good for enterprise/business contexts.
    • Atom One Dark: dark with balanced colours. Good for screenshots that include both code and surrounding light UI.
    • Monokai: classic dark theme, slightly retro feel. Works for teaching content.

    Avoid pure black backgrounds. They look harsh and produce posterised compression artefacts on Twitter’s recompressed images. Dark grey (#1a1b26 or similar) compresses cleaner.

    Typography that exports cleanly

    • Font size 14-18 px for the editor view. The export at 2× will be 28-36 px effective, which reads well on retina displays and projector screens.
    • Use a programming-friendly font. JetBrains Mono, Fira Code, Cascadia Code, IBM Plex Mono — designed for code with clear letterforms. Avoid system monospace; it varies by platform.
    • Line height 1.5-1.6. Tighter is dense; looser is loose. 1.5 reads well across most themes.
    • Width 60-80 characters. Match the visual rhythm of well-formatted code editors. Longer lines truncate visually on social media.

    Common mistakes

    • Wrong language selection. If TypeScript is highlighted as JavaScript, you lose type-syntax colouring. Auto-detect helps but verify before exporting.
    • Tiny font for “show more code”. Cramming 100 lines into one image produces unreadable thumbnails. Better to show 15-20 lines crisply than 100 illegibly.
    • Forgetting to crop padding. Default padding may be excessive; crop tight for use in slides where screen space is limited.
    • Ignoring contrast for accessibility. Some popular themes have low syntax-vs-background contrast. Test the export at typical mobile viewing distance.

    Frequently asked questions

    What languages does the converter support?

    100+ via highlight.js — every major language (JavaScript, TypeScript, Python, Java, Go, Rust, C/C++, C#, PHP, Ruby, Swift, Kotlin), markup (HTML, JSX, TSX, Markdown), data (JSON, YAML, TOML, XML), shell (Bash, Zsh, PowerShell), database (SQL), and many less-common languages.

    Can I share the result directly to Twitter?

    The exported PNG copies to your clipboard or downloads. Paste into your tweet composer, attach the file, or drag-drop. The image is the right aspect ratio for Twitter’s preview without further cropping.

    Is my code uploaded when I use the tool?

    No. The browser highlights your code locally via highlight.js and renders the image on canvas. Your code, the highlighted output, and the PNG export all stay on your device.

    Can I add a watermark or branding?

    Custom watermarks aren’t built in, but the exported PNG is clean — no simpletool.io branding. Add your own watermark in your design tool after export, or use the URL/handle as a small text overlay in the window chrome.

    What’s the resolution of the export?

    2× retina based on the editor view. A 600×400 editor exports at 1200×800 PNG. Sharp on retina displays and good for projector use.

    Why does my code look different in the export than in my IDE?

    IDE colour themes vary — VS Code’s “One Dark” has subtle differences from Atom’s “One Dark”. Pick the closest theme in the converter, or accept slight differences. The semantic colouring (keywords, strings, comments) is consistent; exact hex values differ.

    Related tools and guides

     

  • JWT Decoder Online: Inspect Tokens in Browser [2026]

    JWT Decoder Online: Inspect Tokens in Browser [2026]

    TL;DR: A JWT decoder splits a JSON Web Token into its three Base64-URL-encoded parts — header, payload, signature — and renders them as readable JSON. Use it to inspect what an API token actually claims (user ID, expiry, scopes), debug auth issues, or build new tokens. Our free JWT encoder/decoder handles HS256 and RS256, verifies signatures locally, and never transmits the token.

    JWT (JSON Web Token) is the auth standard for modern APIs. Every OAuth flow, every Auth0 / Cognito / Firebase Auth integration, every internal microservice that needs to pass identity around — all of them use JWTs. The token looks like gibberish: eyJhbGciOi…. Decoded, it’s three small JSON objects that say “this user, signed by this issuer, valid until this time”. Decoding is non-secret — anyone with the token can read its contents. Verifying the signature requires the secret. Both operations are routine for backend developers and frequently need a quick lookup tool.

    Our JWT encoder/decoder takes any JWT string and renders the header + payload as pretty-printed JSON. Optionally paste the secret to verify the signature, or build a fresh token from custom JSON. Everything runs in your browser via the Web Crypto API; the token and secret never transmit. This guide explains JWT structure, the differences between HS256 and RS256, and the security gotchas that have produced real-world authentication failures.

    JWT structure — three Base64-URL parts joined by dots

    eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUiLCJpYXQiOjE2NjcwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
       ↑ header                ↑ payload                                                        ↑ signature
       {"alg":"HS256"}          {"sub":"1234567890","name":"Jane","iat":1667000000}
    • Header: the algorithm used (HS256, RS256, etc.) and the token type. Always JSON.
    • Payload: the claims — user ID, scopes, issued-at, expiry, custom application data. The actual identity assertion.
    • Signature: a cryptographic signature of header.payload using either a shared secret (HS256) or the issuer’s private key (RS256). This is what makes the token tamper-evident.

    Standard claims every JWT might include

    Claim Meaning
    sub Subject — usually the user ID
    iss Issuer — who created the token
    aud Audience — who the token is for
    exp Expiry — Unix timestamp after which the token is invalid
    iat Issued-at — Unix timestamp of token creation
    nbf Not-before — token isn’t valid until this time
    jti JWT ID — unique identifier for revocation lists

    Beyond the standard claims, applications add custom claims (scopes, roles, email, anything else). Decoding a token reveals all claims; this is why JWTs should never carry secrets.

    HS256 vs RS256 — choosing the right algorithm

    • HS256 (HMAC-SHA-256): uses a shared secret known to both signer and verifier. Simpler, faster, smaller signatures. Right when one service signs and the same service verifies. Wrong when verification needs to happen on multiple machines without sharing a secret.
    • RS256 (RSA + SHA-256): uses asymmetric crypto. Issuer holds a private key; verifiers use the public key. Right for any “sign here, verify everywhere” pattern (Auth0, Firebase Auth, Google OAuth all use RS256). The public key can be distributed freely.
    • ES256 (ECDSA): elliptic-curve variant of RS256. Smaller signatures, faster signing, equivalent security. Increasingly common in IoT and mobile contexts.

    The rule of thumb: HS256 for monolithic apps where one service signs and verifies. RS256 for anything multi-service, distributed, or where third parties need to verify.

    How to use the browser JWT decoder

    1. Open the JWT encoder/decoder
    2. Paste your JWT into the input. Header and payload appear as pretty-printed JSON instantly
    3. Optional: paste the signing secret (HS256) or public key (RS256) to verify the signature. Result shows ✓ valid or ✗ invalid
    4. Switch to Encode mode to build a new token from custom JSON
    5. Copy any decoded part with the per-section copy buttons

    Real-world JWT security mistakes

    • The “alg: none” attack. Some libraries trust the algorithm specified in the header. Setting it to “none” tells the library to skip signature verification. Always specify the expected algorithm at verification time.
    • Confusing HS256 with RS256. If a service expects RS256 but accepts HS256 with the public key as the secret, attackers can forge tokens. Always pin the algorithm.
    • Leaving secrets in JWT payloads. JWTs are encoded, not encrypted. Anyone with the token reads the payload. Never put passwords, API keys, or PII in claims.
    • Long expiry times. A 90-day JWT can’t be revoked without maintaining a denylist. Keep exp short (15-60 minutes) and use refresh tokens for sustained sessions.
    • Using HS256 with weak secrets. A 16-byte secret is brute-forceable. Use 32+ bytes (256 bits) of randomness for HS256 secrets.

    Decoding JWT in code

    // Node.js (jsonwebtoken — most common)
    import jwt from "jsonwebtoken";
    
    const decoded = jwt.decode(token);                 // unverified
    const verified = jwt.verify(token, secret);         // throws if invalid
    
    // Browser (jose — modern, no deps)
    import * as jose from "jose";
    
    const decoded = jose.decodeJwt(token);
    const { payload } = await jose.jwtVerify(token, await jose.importJWK(jwk));
    
    // Python (PyJWT)
    import jwt
    decoded = jwt.decode(token, secret, algorithms=["HS256"])
    
    // Manual decode (browser, no library)
    const [header, payload] = token.split(".").slice(0, 2)
      .map(seg => JSON.parse(atob(seg.replace(/-/g, "+").replace(/_/g, "/"))));

    When NOT to use JWT

    • For session storage. Sessions you need to revoke instantly are better as opaque session IDs in a database. JWT revocation requires a denylist that defeats the stateless benefit.
    • For sensitive payload data. Anyone with the token reads the claims. Store sensitive data server-side and reference by ID in the JWT instead.
    • For very long expiry. If your tokens last weeks, you’ve reinvented session storage with extra steps. Use refresh tokens with short-lived JWTs.
    • When you need cookie-based CSRF protection. JWTs in localStorage are vulnerable to XSS; in cookies they’re vulnerable to CSRF. Each pattern has trade-offs to design around.

    Frequently asked questions

    Is JWT encrypted?

    Standard JWT (JWS) is signed but not encrypted — anyone with the token can decode and read the payload. JWE (JSON Web Encryption) is the encrypted variant, much less common. Don’t put secrets in JWT claims.

    Can I decode a JWT without the secret?

    Yes. The header and payload are Base64-URL encoded — anyone can decode them. The secret is only needed to verify the signature (prove the token wasn’t forged) or to create a new token. Decoding without verification is fine for inspection but never trust an unverified JWT in production.

    How long should a JWT expire?

    15-60 minutes for access tokens. Pair with a refresh token (longer expiry, revocable, server-side stored) for sustained sessions. Short access-token expiry limits damage if a token is leaked.

    Is my JWT sent to your server when I decode it?

    No. Decoding happens entirely in your browser via the Web Crypto API and JavaScript Base64 decoding. The token, secret (if you paste one), and decoded output all stay on your device. Verify in DevTools Network tab — no requests during decoding.

    What’s the difference between HS256 and RS256?

    HS256 uses a shared secret known to signer and verifier (symmetric). RS256 uses an RSA key pair where the issuer holds the private key and verifiers use the public key (asymmetric). Use HS256 for one-service contexts, RS256 for distributed/multi-service auth.

    Can I edit a JWT and re-sign it?

    Yes — switch to Encode mode, edit the header or payload JSON, paste the secret, click Sign. The output is a new valid JWT. Useful for testing token-validation logic with custom payloads.

    Related tools and guides

     

  • Base64 Encoder Decoder: Text & Files in Browser [2026]

    Base64 Encoder Decoder: Text & Files in Browser [2026]

    TL;DR: A Base64 encoder/decoder converts arbitrary binary or text data to and from a 64-character ASCII representation safe to embed in URLs, JSON, email, and source code. Text and small files encode in your browser via our free Base64 tool. Use the URL-safe variant (replaces + and / with - and _) for tokens that ride through query strings.

    Base64 is everywhere: data URIs (data:image/png;base64,iVBOR…), email attachments (MIME), JWT tokens, SAML assertions, OAuth flows, the Authorization header in HTTP basic auth, embedded SVG icons in CSS, X.509 certificates wrapped in PEM. It’s not encryption — anyone can decode it — it’s a transport-safe encoding that lets binary data ride through systems that only accept ASCII text. Every developer needs to encode or decode Base64 several times a week, and most reach for an online tool because the language built-ins are awkward.

    Our Base64 encoder/decoder handles text and binary files entirely in your browser — no upload, no server roundtrip. URL-safe variant supported. This guide explains what Base64 actually does, when each variant matters, the security non-confusion (Base64 is not encryption), and the workflows that drive most “base64 encoder online” searches.

    What Base64 actually does

    Base64 takes 3 bytes (24 bits) of input and represents them as 4 ASCII characters (each carrying 6 bits of information, drawn from a 64-character alphabet of A-Z, a-z, 0-9, plus + and /). The 64th character (technically the 65th — =) is padding when the input length isn’t a multiple of 3. The result is always 4/3 the size of the input — a 30 KB image becomes 40 KB of Base64 text.

    • Standard Base64: uses A-Z a-z 0-9 + /. Output may include = padding. Right for email, MIME, most binary-in-text contexts.
    • URL-safe Base64: replaces + with - and / with _. Right for tokens, query strings, filenames — anywhere + and / have other meanings.
    • Base64 with padding stripped: some systems (JWT tokens, OAuth) strip the trailing = padding because it’s redundant when the length is known. The decoder needs to handle both padded and unpadded inputs.

    Five common Base64 use cases

    • Data URIs in CSS or HTML. Inline a small icon or font in your stylesheet to avoid an extra HTTP request: background: url("data:image/svg+xml;base64,PHN2…"). Best for assets under 4-8 KB.
    • HTTP Basic Auth. The Authorization: Basic {base64(username:password)} header. Encoded, not encrypted — always pair with HTTPS.
    • JWT token payloads. Each segment of a JWT is URL-safe Base64. Decoding reveals the header, claims, and signature without verifying authenticity.
    • Email attachments (MIME). Email transports text only; Base64 encodes binary attachments for transport.
    • Storing binary data in JSON. JSON has no native binary type. Base64 wraps the bytes as a string field.

    How to use the browser Base64 tool

    1. Open the Base64 encoder/decoder
    2. Pick a mode: Encode (text/file → Base64) or Decode (Base64 → text/file)
    3. For text: paste into the input area; the result appears live
    4. For files: drop a file into the file panel — the encoded Base64 appears immediately, with a copy button
    5. Toggle URL-safe variant if you need to embed the result in a URL or JWT-style context
    6. Click Copy or Download. Decoded files download with their original or detected MIME type

    All operations run in your browser via the standard btoa / atob primitives plus modern TextEncoder for Unicode handling.

    Base64 in code — every common language

    // JavaScript (browser)
    btoa("Hello, world!");                    // "SGVsbG8sIHdvcmxkIQ=="
    atob("SGVsbG8sIHdvcmxkIQ==");             // "Hello, world!"
    
    // JavaScript (Node) — Buffer is the standard
    Buffer.from("Hello, world!").toString("base64");
    Buffer.from("SGVsbG8sIHdvcmxkIQ==", "base64").toString();
    
    // Python
    import base64
    base64.b64encode(b"Hello, world!").decode()      # "SGVsbG8sIHdvcmxkIQ=="
    base64.b64decode("SGVsbG8sIHdvcmxkIQ==").decode()
    
    # URL-safe variant
    base64.urlsafe_b64encode(b"data?with/special").decode()
    
    // Bash
    echo -n "Hello, world!" | base64                  # SGVsbG8sIHdvcmxkIQ==
    echo "SGVsbG8sIHdvcmxkIQ==" | base64 -d           # Hello, world!
    
    // Go
    import "encoding/base64"
    base64.StdEncoding.EncodeToString([]byte("Hello"))
    base64.URLEncoding.EncodeToString([]byte("Hello"))

    Common Base64 mistakes

    • Confusing Base64 with encryption. Base64 is reversible by anyone — it’s not security. Sensitive data in Base64 is sensitive data in plaintext. Use TLS, encryption (AES, RSA), and hashing (SHA-256) for actual security.
    • Mixing standard and URL-safe variants. A token encoded URL-safe (-_) won’t decode with a standard decoder (expecting +/). Both your encoder and decoder must use the same variant.
    • Forgetting Unicode encoding. JavaScript’s btoa only handles Latin-1 characters by default. For Unicode strings, encode to UTF-8 first: btoa(unescape(encodeURIComponent(str))) or use TextEncoder.
    • Inlining huge images as data URIs. A 500 KB image becomes 670 KB of Base64 — bloats your HTML/CSS, slows initial render. Use data URIs only for assets under ~8 KB.
    • Padding handling. Some systems strip the trailing = from Base64 (notably JWT). Decoders must handle both forms or pad inputs to a multiple of 4 before decoding.

    When NOT to use Base64

    • For storing passwords or secrets. Use proper hashing (Argon2id, bcrypt) for passwords. Base64 of a password protects nothing.
    • For very large files. Base64 inflates size by 33%. Send binary data via multipart/form-data or direct binary uploads instead.
    • For data already URL-safe. If your text is already ASCII without special characters, Base64 just bloats it. Plain text passes through URL params fine after URL-encoding.
    • As a checksum. Base64 doesn’t detect corruption. Use SHA-256 for integrity verification.

    Frequently asked questions

    Is Base64 encryption?

    No. Base64 is encoding, not encryption. Anyone can decode Base64 instantly without a key. It’s the wrong tool for keeping data secret. Use real encryption (AES-GCM, RSA, libsodium) for confidentiality.

    What’s the difference between Base64 and URL-safe Base64?

    Standard Base64 uses + and / in its alphabet. These have special meanings in URLs and filenames, so URL-safe Base64 substitutes - for + and _ for /. JWT tokens, OAuth, and most modern API tokens use the URL-safe variant.

    Why does Base64 add 33% size?

    Three input bytes (24 bits) become four output characters, each storing 6 bits — a 4:3 ratio. The math is fundamental to representing 8-bit data in a 6-bit-per-character alphabet, plus padding. Total inflation is exactly 4/3 of the input.

    Can I encode a file with the browser tool?

    Yes — drop any file into the file panel. The browser reads it via the FileReader API, encodes locally, and shows the Base64 with a copy button. No upload. Works for files up to roughly 100 MB before browser memory becomes the bottleneck.

    What’s the maximum size for a data URI in CSS?

    Practically ~8 KB for a single asset. Beyond that, the bloat to your CSS/HTML outweighs the saved HTTP request. For larger assets, serve as a regular file and let HTTP/2 multiplex the request — modern browsers handle parallel asset loading efficiently.

    Is my data uploaded when I use the tool?

    No. The tool uses browser-native btoa/atob and FileReader API for files. All processing is local. Verify in DevTools Network tab — there are no requests when you encode or decode.

    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