A frontend that is failing, and nothing but the browser between you and the cause. Twelve steps, in the order that actually works, with the tool from the collection at the step where it belongs. Step one: the network panel, the request that is failing, the status code, and the first fork in the road — a 5xx is a server problem, a 4xx is a client problem, and the fork determines the next five steps. Step two: the response body, the error message, the field that is wrong, because the error message is the map and the map is read in the body.
Step three: the JWT decoder, when the failure is a 401 and the token is the suspect — decode it locally, check the expiration, check the claims, and the answer to why now is usually in the payload, which is the step the collection exists to make fast. Step four: the Base64 decoder, when the payload is encoded and the error is in the encoding. Step five: the diff tool, when the working version and the failing version differ by a line you cannot see, because the diff is the eye the browser does not have. Step six: the hash generator, when the asset is cached and the hash tells you which version the browser actually loaded. Steps seven through twelve are the browser's own panels — the console, the application tab, the storage, the performance — in the order the failure usually lives, with the specific symptom that sends you to each panel. The collection's role is the steps the browser cannot do alone: the decodings, the diffs, the hashes. Twelve steps, and the specific tool at each one, with the exact symptom-to-step map that makes the guide a field manual instead of a list. The field is the browser; the manual is the article.
I have written a lot of the DevTools collection content, but this is the one that answers the question people actually ask: how do you actually use it, step by step, from zero? No theory, no marketing. Just the commands, the output, and the decisions you will face along the way. If you have been meaning to try devtools and kept putting it off because the documentation felt like a commitment, this is the version that fits in one sitting. 14 pure-HTML developer tools: converters, generators, and inspectors. Zero install, zero tracking, works offline. — and everything below is what that actually looks like in practice, with the exact outputs you will see and the exact moments where the workflow forks.
14 Tools, One Tab, Zero Install
The collection is fourteen developer tools on a single page: a Cron expression parser, a YAML-to-JSON converter, a URL slug generator, an HTML-to-text converter, a QR code generator, an HTML entities encoder and decoder, a UUID generator, a password generator, a Lorem Ipsum generator, a hash generator for the SHA family, a Base64 encoder and decoder, a JWT decoder, a text diff tool, and a CSV-to-JSON converter. All of them are pure HTML and JavaScript. No install, no extension, no account, no build step. You open the page, you pick a tool, you use it, you close the tab. The design constraint that shaped everything: if a tool needs an install, it will not be used in the moment it is needed, and the moment it is needed is the only moment it matters. Fourteen tools, one tab, zero install — and each one does exactly one job, which is the constraint that makes the collection feel like a drawer of hand tools instead of a software suite. The drawer is the point.
The Generator Family: The Things You Should Never Type by Hand
The generators cover the values that are correct in exactly one way and painful to produce manually. UUIDs for test data and local development. Strong passwords, where the point is the entropy, not the memorability. QR codes for the URL you are about to hand someone at a demo. Placeholder text for the layout that has to exist before the design can be evaluated. URL slugs for the title you are about to publish, with the punctuation stripped and the casing fixed. Each generator is a small answer to a question that comes up dozens of times a year, and the cost of answering it without a tool is low individually and high in aggregate. The collection treats those small costs as the thing to eliminate. The generators are the least dramatic tools in the set and some of the most used, which is the pattern of the whole collection: the quiet tools carry the load, and the dramatic tools are the insurance you hope you never need but are glad is there.
The Converter Family: When Formats Collide
Half of the collection exists for one specific pain: the moment when the format in front of you is not the format you need. YAML from a config file needs to be JSON for the API. CSV from the spreadsheet needs to be JSON for the script. An encoded blob from an error message needs to be readable. An HTML entities dump from a scraped page needs to be plain text. A chunk of HTML needs to be the text inside it. Each converter is small, instant, and client-side — the data you paste is processed in your browser and never transmitted anywhere. The collection is organized so that when the format collision happens, the tool is one tab away, and the answer to how do I convert this stops being a five-minute search and starts being a five-second paste. The converters are the highest-frequency tools in the collection, and the frequency is the point: the tool you use a hundred times a year is worth more than the tool you use a hundred times in one emergency, even though the emergency feels bigger when it happens.
GitHub Pages: Hosting That Costs Nothing and Owes Nothing
The collection lives on static hosting, and that is a deliberate infrastructure decision with a specific shape. No server to pay for, no uptime to manage, no scaling to think about, no vendor lock-in beyond the repository itself. The site is static files in a git repository, and the entire operational model is: commit, push, done. When a tool needs a fix, the fix is a pull request, reviewable like any other code. When the collection needs to move, it is a repository, portable by definition. The tradeoff is real — static hosting means no server-side features, no accounts, no personalization — but every one of those absences is a feature in this design. The hosting is boring on purpose, because the boring infrastructure is the part that is still there in five years. The subscription-based tool you loved last year is the cautionary tale: the tool was good, the hosting model was not, and the tool died with the business model. The static page has no business model to die. It has a repository, and the repository is the model.
The Privacy Argument: Your Data Never Leaves the Tab
The strongest feature of the collection is the one you never see: nothing is transmitted. Every conversion, generation, and inspection happens in your browser, on the page, with no server round trip. That matters most for the tools that handle sensitive input. The token decoder is the obvious example — you are pasting a live token, and a third-party decoder website is a token exfiltration service with a UI. In the local version, the token is decoded in your tab and stays there. The encoded-blob and hash tools are the same story: the input is processed client-side, and the only place your data exists is your machine. For a developer, this tool does not send my data anywhere is not a nice-to-have. It is the difference between a tool and a trust decision, and the collection was built so the trust decision is a one-time yes, made once, by reading the source, which is short enough to actually read. After that, every use is free of the decision. That is the privacy model in one sentence: decide once, by reading the code, and then never decide again.
What I Would Add Next, Honestly
Every collection has a backlog, and being honest about it is more useful than pretending the tool is finished. The candidates in order of value: more converter pairs — the remaining config formats are the obvious gaps; a date-time formatter to sit next to the schedule parser; and a language pass, because the site currently ships in one language while the problems it solves are universal. The candidates I am deliberately not doing: accounts, sync, and personalization. Those are the features that would turn a zero-trust tool into a trust decision, and they are the features that would add a server to a serverless site. The backlog is a list of converters and formatters. Everything else is a different product, and a different product is not the point. The honesty is the feature: the roadmap is short enough to read, the non-roadmap is named, and the reason for each no is the same reason the collection exists in the first place — the tool should stay small enough to trust, and every feature that does not serve that constraint is a feature the collection does not have. The absence is the policy.
Offline-First as a Feature, Not an Absence
The tools work without a network connection, and that is the most underrated property in the collection. Airplane mode: the converters still convert. A flaky office connection: the hash generator still hashes. A conference hall with no signal: the diff tool still diffs. The practical moments are specific and real — the deploy that is failing on a train, the token that needs decoding in a meeting room where the Wi-Fi is a joke, the config that needs converting while the VPN is down. An online-only tool is a tool that is unavailable exactly when the network is the thing that is broken. Offline-first is not a fallback mode. It is the difference between a tool that is always available and a tool that is available when the internet agrees. The property costs nothing to build — it is a consequence of the pure-HTML design — and it shows up in the moments that matter most, which are the moments when everything else in the stack is unavailable and the one thing you need is the small tool that does not need the network to be the thing you need. The offline tool is the last tool standing, and that is exactly where you want it.
Who It Is For, and Who It Is Not
The collection is for the developer who hits a format problem and wants the answer in five seconds, not a five-minute search. It is for the two-in-the-morning token decode, the conference-room QR code, the config conversion on a flaky connection. It is not for the team that needs shared workspaces, audit logs, and admin controls — that is a different category of product with a different trust model. It is not for the power user who wants a plugin ecosystem or a macro system — the tools are deliberately one-job-each. And it is not a replacement for a real IDE or a real debugger; it is the set of small, standalone answers that sit next to those tools. The right frame is a drawer of hand tools: each one small, each one specific, and the drawer is the point. Knowing who it is not for is as useful as knowing who it is for, because the wrong user does not get a bad experience — they get an experience that is missing the features they came for, and the missing features are the named ones, the deliberate absences. The collection is honest about its edge, and the edge is the design.
The Search Bar Is Load-Bearing
The collection has a client-side search bar that filters the fourteen tool cards by name and description, and it is doing more work than it looks. In a fourteen-tool collection, the failure mode is not: the tool does not exist. It is: I do not remember the exact name, and I do not remember which of the three converters it was. The search bar turns that failure into a two-word query: yaml, hash, qr. The implementation is a few lines of JavaScript that filter the page, which is exactly the kind of feature that a framework-based site would treat as a component and a pure-HTML site treats as a paragraph of code. Small features, done without infrastructure, are the signature of the design: every line of the site earns its place, and the search bar is the line that earns the most, because it is the difference between finding the tool in two seconds and not finding it at all. The search is the index of the drawer, and a drawer without an index is a pile. The bar is the difference.
The Usage Numbers on the Cards
Each tool card on the collection shows a usage statistic, and the distribution is a map of what developers actually do. The converters and generators with the highest numbers are the ones that solve a daily, low-level pain: parsing a schedule, generating an identifier, converting between formats. The long tail is the specialized tools that solve a rare but critical pain: decoding a token at two in the morning when the API starts rejecting tokens, or diffing two config files to find the one line that broke the deploy. The pattern is the same as in every toolkit: a few tools carry most of the weight, and the rest are insurance. The collection is built for both halves of that distribution, because the insurance is only worth it if it is there in the moment it is needed. The usage numbers are the only analytics the collection has, and they are displayed next to the tools they describe, which is the honest version of a dashboard: the data is right there, with the thing it measures, and nobody has to ask for the report. The report is the page.
Why Pure HTML Is a Feature, Not a Limitation
Every tool in the collection is a single HTML file. No framework, no build step, no node_modules, no bundle. The consequence is that the tools are smaller than the README that describes them, they load instantly on any connection, they work in airplane mode, and they will still work when the current JavaScript framework of the moment has been abandoned. There is also a maintenance argument: a pure-HTML tool can be reviewed by anyone in the team, fixed with a text editor, and deployed by pushing a file. The build pipeline for the entire collection is a commit. In a category full of tools that need a runtime version and a package manager to run, the absence of both is not a compromise. It is the product. The tool should be as permanent as the problem it solves, and the problems — convert this, generate that, decode this — are as old as the formats themselves. The formats change slowly. The pure-HTML tools change with them, and nothing else in the stack has to change at all. That permanence is the feature.
The takeaway
That is the whole workflow. Open https://wuchunjie00.github.io/devtools/ gets you started, and the repository at https://github.com/wuchunjie00/devtools has the full reference when you need it. If this saved you an hour, a coffee at ko-fi.com/wuchunjie keeps the tools free. And if you want the rest of the toolkit — dotguard for secret scanning, gitpulse for repository analytics, snippetx for snippets — the same npx pattern works for all of them. One command each, zero dependencies each, and a terminal that finally does the mechanical part of the job. The tutorial ends here; the habit starts now.
Top comments (0)