Does devdeck upload JSON, YAML, Base64 or regex input to a server?

No. Current devdeck tools run in the browser. In the Network tab you should see site assets and analytics metadata, not your source payload.

Is Base64 a way to protect data?

No. Base64 is encoding, not encryption. Anyone can decode the string back.

Does the JSON formatter validate my business schema?

No. It checks JSON syntax with the browser parser. Field types, required keys and business rules need separate schema validation.

Does the regex tester use PCRE?

No. It uses JavaScript RegExp in the current browser. Behavior can differ from PCRE, RE2, Java or Python.

Local developer tools in the browser - when it is actually safe

A staging secret lands inside a JSON payload. There is a bearer token, a user id, two internal feature flags and a 300-line API response. You need to format it, find the broken comma and avoid putting that text into someone else's request history.

A browser tool is fine for that only under one condition: processing must happen inside the current tab. Not "we delete it after an hour", not "we respect your privacy", just the boring check: open DevTools, switch to Network, click the button and confirm that the payload did not leave.

The current devdeck tools are built for that workflow: JSON formatter, YAML formatter, Base64, UUID generator and Regex tester run locally in the browser.

Quick check before pasting data

Input	Fine in devdeck	Caveat
API response JSON	Yes, for text JSON of reasonable size	Syntax only, not business schema
Kubernetes YAML	Yes, for formatting and parser errors	It does not validate against your cluster
Base64 token	Yes, for encode/decode	Base64 does not hide data
UUIDs for test records	Yes	Generated UUIDs are dev/test ids, not a database ordering guarantee
Regex pattern and sample log	Yes	Flavor is JavaScript RegExp, not PCRE

If the payload is large enough to freeze the tab for seconds, privacy is not the only concern. It is the wrong tool. For a 50 MB JSON file, use jq. For CI YAML, use the parser in your repository. For production log patterns, put a test next to the code.

Where "local" ends

Local processing removes one risk: uploading text to the tool server. It does not make the data magically safe. The clipboard still exists. Browser extensions still exist. So do screenshots, enterprise DLP and whatever you intentionally save from the page.

Base64 is the easiest trap. A string like eyJ1c2VySWQiOjEyMywicm9sZSI6ImFkbWluIn0= looks token-ish, but it is just encoded JSON. Anyone can decode it. The Base64 tool is useful for debugging; it is not encryption and it does not turn a secret into safe text.

JSON has a similar trap. The JSON formatter says "valid" when the document can be parsed as JSON. It does not know that price must be a number, status must be one of five values, or createdAt must be an ISO date. Use JSON Schema, Zod, an OpenAPI validator or your own code for that.

Why not just use a CLI

Often you should. jq, yq, uuidgen, openssl base64 and regex tests inside the project are the right tools for repeated work.

The browser wins for the small awkward cases: you are on a borrowed machine, checking one payload from an issue, comparing two regex variants or generating 20 UUIDs for a test seed. No package install, no flag hunting, no command recall. Open the tab, do the work, close it.

What to check in the Network tab

Open DevTools, go to Network, clear the request list and press the tool button. A local formatter should not create a POST, PUT or fetch request with your text. Requests for JS, CSS, favicon and analytics may exist, but the source payload should not appear in a request body, query string or URL path.

That check is crude, but it is more useful than a privacy page. A policy can promise deletion after an hour. The Network tab shows whether an upload happened at all.

The rule of thumb is plain enough: devdeck for short developer payloads; a local CLI or repository test for large files, production secrets and mandatory schema validation.