Browser tools execute entirely on your device — your data never leaves. Server tools make SSRF-hardened, bounded requests to query public records; input is processed but not stored.

FOR DEVELOPERS

Automate the tools you need.

Most tools expose POST /api/v1/tools/[slug] with JSON in/out. A few are browser-only by design for privacy or security.

# hash via API

curl -X POST https://yas.sh/api/v1/tools/hash-calculator \

-H "Content-Type: application/json" \

-d '{"input":"hello","algo":"sha256"}'

Tools API reference →

Execution modes, clearly labeled

🔒 Browser (client-side) private, offline-capable
🌐 YAS server-side SSRF-hardened YAS infrastructure
API available POST /api/v1/tools/:slug
API: browser-only browser-only, explained on-page

About the YAS.SH tool directory

This directory collects 100 single-purpose utilities for people who build, operate and debug things on the web: developers, systems and network engineers, email administrators, security researchers and technical marketers. Each tool does one job — format a JSON document, resolve a DNS record, decode a JWT, check an SPF policy, calculate a subnet — and every one of them is free to use without an account, without a trial and without a usage form.

The tools are not a collection of wrappers around one library. They are grouped into seven domains, and each domain reflects a different class of problem: data you need to reshape, credentials you need to generate or inspect, URLs you need to build or take apart, infrastructure you need to interrogate, mail authentication you need to verify, text you need to transform, and everyday conversions that are quicker here than in a terminal.

Every tool page carries the tool itself plus documentation of the standard it implements: how the mechanism actually works, the situations it is for, the mistakes people make with it, and an honest statement of what it does not do. That last part matters more than it sounds — a tool that quietly disagrees with the specification is worse than no tool, so the constraints are written down rather than discovered later.

What you can do here

Reshape and validate data
Format, minify and validate JSON, XML, YAML, TOML and CSV; convert between them; generate TypeScript interfaces from a sample payload; repair malformed JSON returned by a language model.
Generate and inspect credentials
Produce passwords, passphrases, UUIDs, ULIDs and NanoIDs from a cryptographically secure source; compute hashes and HMACs; decode a JWT; check a bcrypt hash; read a TLS certificate.
Diagnose infrastructure
Resolve DNS records, trace redirect chains, read HTTP response headers, analyse a TLS configuration, check certificate expiry, calculate CIDR ranges and inspect a User-Agent string.
Verify email authentication
Inspect SPF, DKIM and DMARC records, check MX health and reverse DNS, validate MTA-STS and TLS-RPT, audit DNSBL reputation and plan a sending warm-up schedule.
Work with URLs and links
Encode and decode, parse a URL into its components, build UTM campaign links, strip tracking parameters, expand shortened or multiply-encoded links and generate QR codes.
Automate any of it
Most tools expose the same computation at POST /api/v1/tools/:slug with JSON in and JSON out, documented per tool with cURL, JavaScript and Python examples.

How the tools run, and why that is labelled on every page

Each tool declares where its computation happens, because that determines what leaves your machine. Client-side tools run entirely in your browser using standard web APIs — the JSON parser, Web Crypto, TextEncoder — so the data you paste never crosses the network and the tool keeps working with the connection dropped. Server-side tools run on YAS infrastructure because they genuinely need to: resolving a DNS record or opening a TLS connection to a host cannot be done from a browser tab.

A small number of tools are browser-only by deliberate choice rather than technical necessity. Anything that would let an anonymous user make arbitrary outbound requests from our servers is a server-side request forgery risk, so those tools stay in the browser and the page says so explicitly instead of quietly offering an API that does not exist.

The badges on each tool card and each tool page state the execution mode, whether an API endpoint is available, whether the tool works offline, and the skill level the tool assumes. None of these are marketing labels — they are read from the same catalogue that drives the API and the documentation, and a contract test fails the build if they ever disagree.

How this helps in practice

The common thread is removing friction from a task that is too small to justify writing a script and too fiddly to do reliably by hand. Checking whether a certificate covers the right hostnames, confirming that an SPF record is under the ten-lookup limit, or working out why a JSON payload will not parse are each a few minutes of work with the right tool and a much longer afternoon without one.

The second thread is correctness. Many of these operations have a specification behind them that most implementations approximate: RFC 4180 for CSV quoting, RFC 3986 versus form-urlencoding for spaces in URLs, RFC 7208 for SPF evaluation limits, RFC 9562 for UUID versions. Where a specification exists, the tool follows it and the page names it, so you can check the behaviour against the source rather than trusting a black box.

Who this is for

Developers debugging an API payload, a token or a build configuration.
Network and systems engineers checking DNS, TLS and HTTP behaviour from outside their own infrastructure.
Email administrators diagnosing deliverability and authentication.
Security researchers and students who want the mechanism explained, not just the answer.
Technical marketers building campaign links and QR codes that are actually attributable.

Frequently asked questions

Are the tools really free, and is there a catch?

They are free, with no account required and no usage cap on the pages themselves. The site is funded by advertising on a subset of pages and by paid plans for the link-shortening and monitoring products, which are separate from these utilities.

Is the data I paste kept or logged?

Client-side tools never transmit your input at all — the computation happens in the browser tab. Server-side tools receive the input needed to perform the request and do not retain it after the response. Each tool page states which mode it uses, and the Privacy Policy covers this in detail.

Can I use these tools from scripts instead of the browser?

Yes. Most tools expose POST /api/v1/tools/:slug with a JSON body and a JSON response, documented on each tool page with cURL, JavaScript and Python examples. A few tools are browser-only for privacy or server-side request forgery reasons, and those pages say so explicitly.

Do the tools work offline?

Client-side tools continue to work once the page has loaded, because the computation uses browser APIs rather than a network call. Tools that inspect remote infrastructure — DNS, TLS, HTTP — obviously cannot.

How do I find the right tool for a task?

Use the search box, filter by group, or browse the workflow packs, which group tools by the job you are doing rather than by the technology they touch. Every tool page also lists related tools for the next step in the same workflow.

Which tools should I not use for production secrets?

Any tool that runs server-side receives what you send it, so do not submit production signing keys, real passwords or live tokens. Key and seed generators here are for learning and testing; production key material should be generated on the machine or hardware module that will hold it.

If a tool is missing something you expected, or its output disagrees with another implementation, that is worth telling us about — the limitations sections on each page exist precisely because the disagreements are usually specification details rather than bugs, and documenting them is more useful than pretending they are not there.