About
16 free tools and 22 guides for building with language models, all processing your input in your own browser.
What this is
devtools.codes is a small set of free utilities for people building software with large language models. Counting tokens and estimating what an API call will cost, writing a JSON Schema a model will actually follow, working out why a structured response failed validation, checking an MCP server configuration, choosing chunk settings before indexing a corpus, and catching a credential before it reaches a commit.
The tools exist because each one was a job that needed doing repeatedly and the available options were worse than they needed to be: a login wall in front of a text box, a page that reformats your input without asking, or a service that wants your production prompt uploaded to find out how long it is. Every tool here does one job, states plainly what it cannot do, and gets out of the way.
Alongside the tools are a set of task guides that answer one question each, with the relevant tool built into the page. They exist because the question a person actually types into a search engine is rarely the name of a tool. It is usually a problem, phrased as a problem.
Why everything runs in your browser
Every tool on this site does its work in the page, using your own device. Nothing you type is sent anywhere to be processed, because there is no server-side processing to send it to.
That is a deliberate design constraint rather than a technical accident, and the reason is the nature of the input. A prompt pasted into a token counter is usually a real production prompt. A JSON payload pasted into a validator is often a real customer record. Text pasted into a secret scanner is, by definition, suspected of containing a live credential. Asking someone to upload any of that to find out a character count is a poor trade, and it is the trade most comparable tools quietly ask you to make.
The honest version of the claim matters too, so here it is in full. Your tool input is processed locally in your browser and is not intentionally uploaded to our servers. Advertising and analytics providers may still process normal page, device, cookie and network information. The second sentence is not a disclaimer bolted onto the first — a page that carries advertising is making network requests, and saying otherwise would be misleading however good the first sentence sounds.
What it deliberately does not do
There is no account, and no way to make one. Nothing is stored against you because there is nothing to store it against. The site keeps two things on your own device: your theme preference, and your cookie choices. Neither is sent anywhere.
No tool calls an AI model. Every result is produced by ordinary deterministic code, which means the same input gives the same output, the reasoning can be explained, and there is no third party receiving your text in order to answer a question about it. For a site aimed at people who build with language models, not using one is a considered position rather than an oversight.
Nothing you enter is ever written to a database, a log line, an analytics event or a URL. Input is never silently reformatted or repaired, even when it fails to parse, because a tool that quietly rewrites what you pasted has destroyed the evidence you came to inspect.
How it is paid for
The site is free and is funded by advertising. That arrangement is worth being direct about, because it is the part most sites explain least.
Advertisements never appear between an input and its result, beside an action button, inside an error message, or anywhere in the sequence of getting a job done. They load only after you have agreed to them, and if you decline they are not requested at all. The Secret Scanner carries no advertising on any screen size and does not load an advertising script at all, because a page where people paste credentials is not a page that should be making requests to an ad network.
These are fixed constraints rather than current preferences. They are enforced by automated tests that fail the build, which is a more reliable guarantee than an intention stated on a page like this one.
How it is built, and how it is checked
This site is built with AI-assisted development, and it is worth saying so directly rather than leaving you to guess. The code is written with an AI assistant, then read, tested and reviewed by a person before any of it ships. That is the same arrangement a great deal of software now uses; the difference is that most sites do not mention it.
What that means in practice is a process rather than a promise. Every tool has automated tests covering its processing logic, and those tests run before each release — the suite currently stands at over five hundred assertions. The rules the tools enforce are ordinary deterministic code, so the same input always produces the same output and the reasoning can be explained. No tool calls an AI model to produce your result.
It also means the site is a working project rather than a finished commercial product, and some of it exists to be learned from as much as used. That is not a disclaimer to excuse a poor result; the tools are meant to be correct, and where one is not, that is a bug rather than an accepted limitation. If you find one, the contact page reaches the person who can fix it, and a specific report is genuinely welcome.
Who makes it
The site is built and maintained by a student, working on it independently around other commitments. It is not a company, it has no team, and there is no support department behind it. Anything you send through the contact page is read by the same person who writes the tools.
That is worth knowing before you write in, because it sets a realistic expectation: messages are read and replied to by one person, around other work. It also means corrections are genuinely welcome. If a guide is wrong, a price is out of date, or a tool reports something it should not, saying so is the fastest route to it being fixed.
Getting in touch
Corrections, bug reports and suggestions all go to the same place. Write to [email protected], or read the contact page first if you are reporting a fault — it explains what is useful to include, and what should never be sent by email.