All Tools in one place

BuildToolForge is a free online toolbox for the checks that come up in everyday web, DNS and security work. Each tool does one job, runs in your browser and explains what the result means instead of handing you raw output — so you finish with an answer you can act on rather than a dump you still have to read. The collection grows steadily, and every tool works the same way: open the page, paste what you have, read the answer.

Every tool is free, with no account, no subscription and no usage cap. Most of the work happens in your browser rather than on a server: the DNS lookups go straight from your device to public DNS-over-HTTPS resolvers, and the calculators and reference tools never send your input anywhere at all. Nothing you type is stored, nothing is sold, and what you enter into a tool is never used for advertising. Pages are kept deliberately light so they load quickly on a phone on mobile data, which is where a lot of urgent debugging actually happens.

The tools are grouped by the kind of problem they solve. DNS & Networking is where you go when a domain will not resolve, a record change has not propagated, or you need to confirm which nameservers are authoritative. HTTP covers the request and response layer — status codes and API rate limits — which is usually where a broken deployment or a misconfigured CDN shows itself first. Security handles certificates, browser protections and the tokens behind a login: certificate expiry, chain problems, the response headers that decide whether a browser will enforce HTTPS, and what a JSON Web Token actually says. Encoding is for the data-shuffling jobs that come up in the middle of all of that — turning bytes into something you can paste into a header, a config file or a ticket, and back again.

This is a growing collection rather than a finished product, and the roadmap above is the honest version of what is coming next — each of those tools will run in the browser the same way the current ones do. If a tool you need is missing, or one of the existing ones gets something wrong, the contact page has a working email address and we read every message. Step-by-step guides for the bigger topics live on the blog, so you can read why a check matters as well as run it.

A result is only as good as the question behind it. These habits come from years of debugging live websites, and they save time whichever check you run.

Test from outside your own network

Your laptop, your office router and your browser all keep their own caches. A lookup that runs against public resolvers, or from our server, shows what the rest of the internet sees — usually the answer you need when a customer reports a problem that you cannot reproduce.

Record the current value before you change it

Note the DNS answer, the certificate expiry date or the list of headers before you touch anything. After the change you can confirm that it worked, and you have an exact copy to roll back to if it did not.

Allow for caching

DNS records, redirects and many headers are cached for as long as the server allows. If a fix does not show up straight away, check the TTL or cache lifetime before assuming it failed; often a few minutes of waiting is the whole solution.

Read the verdict first, then the details

Each page opens with a short verdict — valid, missing, expiring soon, too permissive — followed by the underlying values. Start with the verdict, and use the details when you need to explain the issue to a hosting provider, a registrar or a colleague.

Keep sensitive data safe

Tokens, encoded strings and generated policies are processed in your browser. Even so, use a test token where you can, and rotate any secret that you have pasted somewhere you do not fully control.

Check again after every deployment

Most regressions arrive with a release: a header dropped by a new proxy, a certificate that was not renewed on one host, an SPF record overwritten by a new email provider. A two-minute check after each deployment catches these before your users do.

Compare more than one resolver

Different DNS resolvers can hold different answers for a while, especially right after a change. Comparing Cloudflare, Google and Quad9 in the DNS lookup shows whether a record has spread everywhere or only reached some networks — often the difference between “it works for me” and “it is broken for everyone else”.

Share results with context

When you send a result to a provider or a colleague, include the time of the check, the exact domain or URL you tested and the verdict. That context saves a round of questions and makes it easy to compare a later check with the first one.

Learn the pattern, not just the fix

Most issues repeat: the same forgotten SPF include, the same header removed by a proxy, the same certificate that renews on one server but not on another. Reading the linked guide once turns a single fix into a checklist you can reuse on every project.

Each page also links to an in-depth guide on the same topic, with worked examples and the mistakes we see most often, so you can go from a quick answer to a full understanding whenever you need it.