Fourteen tools, one page, and this is the tour — each tool gets its job, its input, its output, and the specific moment it earns its place. The converters first: YAML to JSON for the config that the API wants as JSON, CSV to JSON for the spreadsheet that the script wants as data, Base64 for the blob in the error message, HTML entities for the dump from the scraper, and HTML to text for the page that needs its words. The generators next: UUIDs for the test data, passwords for the account that needs entropy, QR codes for the demo, placeholder text for the layout, and URL slugs for the publish.
The inspectors last: the Cron parser for the schedule that is not a sentence, the hash generator for the download that needs verifying, the JWT decoder for the token that needs its expiration, and the diff tool for the two files that differ by one line. Every tool is pure HTML, every input stays in your browser, and the tour ends with the privacy property that makes the whole collection safe to use on sensitive data, because the sensitive data is the real test of any tool, and the test is the property that nothing leaves the tab. Fourteen tools, one tab, zero install — and the specific job of each, with the exact input and output shapes, so you can follow the tour in your own browser while you read, which is the point of the tour: by the end, the page is not a page, it is a drawer you know, tool by tool, the way you know a physical drawer, by the shape of each tool in its slot. The tour is the article; the drawer is the point.
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.
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.
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.
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.
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.
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.
Pairing the Browser Tools With the CLI Toolkit
The browser collection and the CLI tools cover the same developer day from two angles. In the terminal: the scaffolder generates the project, the secret scanner checks it, the git analytics measure the repository, the snippet manager stores the code that falls out. In the browser: the converters handle the format collisions, the generators produce the values, the inspectors decode the artifacts. The day is one continuous loop of mechanical problems, and the toolkit is the set of small answers to each of them. The two halves are independent — the browser tools do not need the CLI, and the CLI does not need the browser — but the pattern is the same in both: a specific, frequent, mechanical task, answered by a tool that does exactly that and nothing else. Collectively, they are a working theory of what a modern developer's toolkit should look like: small, single-purpose, zero-ceremony, and always available. The theory is not in the tools individually; it is in the set, and the set is the argument. Each tool is a sentence, and the toolkit is the paragraph that makes sense.
The Inspector Family: Reading What You Cannot Parse in Your Head
Inspectors are for the artifacts that are structured but not human-readable at a glance. The Cron expression parser turns a schedule into a sentence and a visualization of when it fires. The JWT decoder splits a token into its header, payload, and signature, and shows you the claims — including the expiration, which is the answer to why is this failing now. The hash generator computes digests for text, which is the verification step after a download. The diff tool highlights the exact lines that differ between two versions of anything. The common thread: the artifact is right there in front of you, but reading it correctly takes a tool. The collection is that tool, for the artifacts every developer meets. The inspectors are the tools that save the most time per use, because the alternative is not a small cost — it is a wrong answer, and the wrong answer in a schedule or a token or a checksum is the kind of error that costs an hour to find. The inspector finds it in five seconds, which is the entire value proposition of the family.
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.
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.
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 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 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)