NoSignups (FckSignups): a curated in-browser tool directory with no accounts

The problem NoSignups addresses: signup walls between you and a one-off task

Most online utilities ask for an email before they do anything. For a single image conversion or a quick text transformation, that exchange is a poor trade: you give up an address and accept tracking in return for a task that should take seconds. NoSignups is a directory built around the opposite rule. The README states the project's contribution guideline plainly: the tool must work without creating an account. The site describes itself as a curated collection of open-source tools usable instantly in a browser, with no accounts, no emails and no tracking on the directory itself.

The audience is narrow but real. It is for engineers and tinkerers who want a bookmarkable index of browser tools that do not demand registration, and for people who want to run that index on their own infrastructure. It is not a tool that performs conversions or edits; it is a catalog. That distinction matters, because the value of a catalog is entirely in its entries and its filtering, not in any processing it does.

How the directory is put together: React, Vite, and a single tools.json

The repository is a Vite project. package.json declares React 19 and React DOM 19 as dependencies, with TypeScript, Vite, the React plugin and vite-plugin-html as dev dependencies. The scripts are dev, build, preview and deploy, where build runs tsc followed by vite build and deploy runs npx wrangler deploy. The presence of wrangler.toml and a cloudflare-worker/ directory indicates the site is intended to be served through Cloudflare Workers.

The data lives in tools.json at the repository root rather than inside src. Each entry follows the schema documented in the README: id, name, description, url and category are required; tags, github, license, stars, featured and notRecommendedReason are optional. The category field must match a category id, and the README lists the defaults: all, productivity, design, development, writing, privacy, utilities, data, media and education. A tags array drives search, and featured pins an entry to the top. The notRecommendedReason field is the most opinionated part of the schema: it lets a listed tool carry a visible caveat instead of being silently dropped.

That is the whole architecture. There is no database, no user accounts and no server-side rendering step described in the README. The site is a static build over a JSON file, which is why the project can claim no cookies and no analytics on the directory itself. The trade-off is that freshness depends entirely on human edits to tools.json; nothing in the repository layout suggests automated link checking or health monitoring.

Running NoSignups locally: clone, install, npm run dev

The README gives a single command that clones the repository, installs dependencies and starts the development server. It assumes Node and npm are already available.

git clone https://github.com/BraveOPotato/FckSignups.git && \
cd FckSignups && \
npm install && \
npm run dev

After that, Vite prints a local URL in the terminal and the directory renders in the browser. The README does not state which port it uses, so treat the printed URL as authoritative.

The README documents no other command for building or previewing the site, so the scripts in package.json are the reference for anything beyond local development. One of them, build, runs tsc before vite build, which means a type error in the TypeScript sources fails the build before Vite emits anything.

To add your own entry, edit tools.json. The README's contribution guidelines say descriptions should stay under 140 characters and each tool should carry three to five relevant tags. The documented fields are the only ones to use; the README does not show a filled-in example entry, so build yours from the schema table.

The id must be URL-friendly and unique, and the category value must match one of the ids listed in the README or the entry will not appear under any filter. The README does not document what happens when category does not match, so verify that in your own copy before publishing.

Where NoSignups gets in the way: curation is manual and the schema is permissive

The most obvious limitation is that the directory is only as good as its last edit. The README does not describe any scheduled job, link checker or automated validation of the entries. A tool can be listed, change its terms, start requiring an account, and remain in tools.json until a human notices. The contribution rule that tools must work without creating an account is a policy, not a test.

The schema also accepts optional fields without enforcing them. github, license and stars are all optional, which means a large share of entries can be listed with no source link and no licence identifier. For a project whose stated philosophy is that open source is the default, the schema does not require the evidence. The stars field is documented as being for display, and the README's featured section is explicit that featuring is a subjective call by the maintainer: the README says the maintainer flags tools that are different from the others and describes the process as biased. That is honest, but it means the ordering at the top of the list reflects one person's taste rather than a measured ranking.

Finally, NoSignups is the wrong tool if you want a hosted service with an SLA. It is a static directory you run yourself. If what you actually need is a single conversion utility, the directory will send you elsewhere; it does not perform the work.

How NoSignups differs from awesome-list style directories

The closest alternative is a curated Markdown list, the kind hosted in a repository and rendered by the code host. Those lists share the same editorial model as NoSignups: a human decides what goes in, and the list is only as fresh as the last commit. The difference is the interface. A Markdown list gives you a linear document with no category filter, no tag search and no way to pin an entry. NoSignups turns the same editorial model into a small React application with category filters and tag-based search, and it adds a structured schema with a category field that must match a known id.

A second difference is the deployment story. A Markdown list is read on the code host. NoSignups builds to static assets and, based on wrangler.toml and the cloudflare-worker/ directory, is meant to be deployed to Cloudflare Workers. That means you can serve the directory from your own domain with no third-party rendering in the path, which matches the project's claim of no cookies and no analytics on the directory. The cost is that you now own the deployment, the build and the data file. There is no upstream feed to subscribe to; updating means pulling the repository and rebuilding.

Licence and maintenance cost of running the directory

The README states that the NoSignups directory code is released under GPL-3.0, and the repository carries a LICENSE file at the top level. The same paragraph states that individual tools listed in the directory retain their own licences and that the project does not claim ownership of any third-party projects. That split matters if you fork the directory and redistribute it: the code you fork is GPL-3.0, while the entries point at software under other terms. The schema's optional license field is the only place those terms are recorded, and it is not required, so a fork that relies on the directory to track licences will have gaps. This is a description of what the repository says, not legal advice; if you plan to redistribute, read the LICENSE file and the individual tool licences yourself.

Maintenance cost is dominated by the data file, not the code. The React and Vite layer is small and the dependency list is short, but every entry you add or verify is manual work. The repository was last pushed on 2026-09-14, which is recent, and it is not archived. There are no releases listed, so upgrades are tracked through commits rather than versioned tags. If you deploy your own copy, plan for periodic pulls and rebuilds rather than a package you can bump.

Editorial conclusion

Adopt NoSignups if you want a self-hosted, no-account directory of browser tools and you are willing to maintain the tools.json entries yourself, since the project states that inclusion requires the tool to work without creating an account. Do not adopt it if you need a hosted service with a support contract or if you expect the directory to stay current on its own; the README does not document any automated link checking or staleness detection. Before deploying, verify the tools.json schema against the fields you intend to use, confirm that the GPL-3.0 licence on the directory code is compatible with how you plan to redistribute it, and check that the individual tool licences listed in the entries match what you are willing to ship.

Frequently asked questions

Official sources

1. BraveOPotato/FckSignups on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README