A tool catalogue that tells you the truth about itself
Tool Fly is a free collection of browser-based tools for documents, images, video, code, writing, study, freelancing and everyday planning. Most of them do their work inside your own browser. The two that need our server say so, on the card and on the tool page, instead of hiding behind a privacy slogan.
This page explains what the project is, where it came from, how a tool actually runs, what we check before a tool is called finished, and what we have not built yet.
- 2,664
- tools in the catalogue
- 2,662
- run inside your browser
- 2
- need our server
- 25
- departments with working tools
Why Tool Fly exists
Most online tool sites make you create an account, upload a file to a server you know nothing about, and then describe the whole thing as "secure". Tool Fly was built on the opposite idea: if a job can be done in the browser, do it in the browser, and be precise about the two exceptions.
The practical version of that idea is simple. A PDF merge does not need a server. A unit converter does not need a server. A password generator does not need a server. When the work happens on your device, the file never has to travel, the result is instant, and there is nothing for us to store in the first place.
Where a tool genuinely cannot run in the browser — reading a web page that blocks cross-origin requests, for example — we use the server and we say so. A visitor should never have to guess where their document went.
The second half of the idea is about wording. A tool catalogue is only useful if its descriptions are accurate. Every tool carries the file or text it works on, the format it accepts, and the limits it has. When a feature is not ready, it is marked as such rather than shipped with a promise.
Say where the work happens
Every tool page and every tool card shows one of three badges: "Runs in your browser", "Uses our server", or "Uses our server for some steps". The badge comes from the tool registry, so it cannot drift away from what the code does.
Do not invent what we cannot prove
There are no customer testimonials, star ratings, user counts or traffic numbers on this site, because we do not have verified figures for them. The counts on this site are counts of the catalogue itself, computed from the registry.
Ship the limitation with the feature
A converter that uses a stored rate table says so and shows the date the table was reviewed. A temporary inbox that runs in your browser says that it does not receive real mail. Limits are part of the description.
Keep the tool, drop the friction
No account, no install, no paywall, no upload queue. Open a tool, do the job, take the result. If a tool needs a server, the wait is short and the reason is stated.
How the project grew
The order below is the order the work actually happened in. Each entry describes a step that is visible in the repository, not a milestone that was announced somewhere else.
First step
One department, one honest engine
The project started with a small set of document tools that ran entirely in the browser. The point was not the number of tools; it was proving that a browser-side PDF tool could be fast and useful without a server in the middle.
Next
A typed registry instead of scattered pages
Every tool moved into one typed registry. A tool became a record with a route, an engine, its accepted inputs, its capabilities, its limitations and its search copy. Adding a department stopped meaning writing a new page from scratch.
Then
Departments for how people actually work
Tools were grouped by task rather than by file type: documents, images, video, code, writing, study, freelancing, business planning and general utilities, plus a large calculator collection. The catalogue grew department by department.
Later
The parts that cannot run in a browser
Two features need the server and were kept because they are genuinely useful: reading the metadata of a link that blocks cross-origin requests, and forwarding a prompt to a model provider when you ask for a model answer. Both are marked on their pages.
Recently
Claims turned into checked facts
Every privacy and accessibility claim across the interface was checked against the code that runs. The absolute wording was replaced with specific statements, the badges were added, and the counts on the site began to be computed from the registry instead of written by hand.
Now
An About page that can be audited
This page is the result. The privacy table below is generated from the tool registry, the counts come from the same registry, the structured data matches what the page renders, and every statement about a limit is a statement we can point at in the code.
What happens when you open a tool
The route for a browser-side tool is the same from the first request to the last download. Nothing in this path needs a server that holds your file.
You pick a tool
Every department page lists the tools it holds with a badge showing where the work happens. Filters and search narrow the list down; the badges stay visible so the choice is made with the processing in mind.
The tool loads in your tab
The page is served as a static file. The tool script runs in the same tab as the page, with the same permissions the page already has. There is no queue, no job id and no status to poll.
The work happens on your device
The engine reads your input in browser memory, applies the transformation, and hands the result back to the page. For a file tool that means the bytes are not sent to us; for a text tool it means the text is not sent to us.
You take the result away
The output is shown on the page and offered as a copy or a download. If the tool needs our server for one step, that step is stated on the card and on the tool page before you use it.
Where the work of each department happens
This table is not written by hand. It is rebuilt from the tool registry every time the page loads, so it always describes the catalogue that is actually published. A department that grows, shrinks or moves a tool to the server is reflected here without anyone editing a sentence.
| Department | Tools | Runs in your browser | Uses our server | Uses our server for some steps |
|---|---|---|---|---|
| Text & Writing Tools | 382 | 382 | — | — |
| General Utilities | 254 | 254 | — | — |
| Inventory & Business | 233 | 233 | — | — |
| PDF Tools | 221 | 221 | — | — |
| Developer & Coding Tools | 218 | 218 | — | — |
| AI Productivity Studio | 202 | 201 | — | 1 |
| Study Companion | 159 | 159 | — | — |
| Word & Document Tools | 142 | 142 | — | — |
| Image & Media Tools | 127 | 127 | — | — |
| Logo & Branding Studio | 120 | 120 | — | — |
| Video Tools | 116 | 116 | — | — |
| QR & Barcode Tools | 114 | 114 | — | — |
| Design Tools | 110 | 110 | — | — |
| Freelancer Tools | 108 | 108 | — | — |
| Resume Builder & Career Productivity | 104 | 104 | — | — |
| SEO Tools | 11 | 10 | 1 | — |
| Colors & Accessibility | 10 | 10 | — | — |
| CSS Tools | 10 | 10 | — | — |
| Data Conversion | 10 | 10 | — | — |
| Data Tools | 10 | 10 | — | — |
| Color Palette Studio | 1 | 1 | — | — |
| Favicon Design Studio | 1 | 1 | — | — |
| Invoice Studio | 1 | 1 | — | — |
| All departments | 2,664 | 2,662 | 1 | 1 |
The tools that need our server
These are the only two tools in the catalogue that send anything to a backend. Both carry a badge on their card and on their own page, and both explain in the tool page what is sent and what is not.
- Link Preview GeneratorUses our server
The address you paste is sent to our server so it can read the page and return its title, description and image. The address is not stored.
- Tool Fly AI AssistantUses our server for some steps
The local answer is built in your browser. When you pick a model, your prompt is sent through our server to that model provider.
Every department, and what is in it
The catalogue is grouped by the job you want to do rather than by the file you happen to have. The counts below are the number of tools in each department right now, and they are counted from the registry rather than typed in.
A department page lists every tool it holds with a badge that shows where that tool does its work, so you can see before you open one whether it stays in your browser or needs our server.
A few of the tools
The catalogue holds far more than can be shown on one page. These twelve come from different departments, and each one carries the same processing badge you will find on its card and on its own page.
Runs in your browser · Uses our server · Uses our server for some steps — one badge per tool, taken from the registry.
How a tool is checked before it ships
A tool is marked "working" only when it does the job it describes. The checks below are the ones that run in this repository, on every build.
The registry validates itself
Every tool record is checked at start-up. The route has to be unique, the example input has to use fields the tool declares, the engine binding has to exist, and the tool has to have a real implementation behind it. A record that does not satisfy these rules stops the application from loading.
Every tool page is rendered in the build
The build pre-renders the whole catalogue and checks the output. A page that is missing its title, its canonical link or its structured data fails the build rather than shipping broken.
The search copy is checked for collisions
Two tools cannot claim the same search title. Duplicated titles are a real problem for a catalogue this size, because they make two different tools look like the same page to a reader and to a search engine.
The behaviour of the flows is covered by tests
The repository carries an automated test suite that covers the shared flows: the search palette, the department filtering, the Back control that returns you to the department you came from, the account areas and the tool registry itself.
The privacy wording is matched to the code
When a tool talks about where its data goes, that wording is reviewed against the engine it runs. This is how the currency converter stopped claiming live server rates and the temporary inbox stopped claiming to poll a mail gateway.
What runs on every build
- Typed metadata for every tool, checked when the application starts.
- A pre-render step that fails the build on a missing title, description or canonical link.
- A structured-data check that compares the page output with the JSON-LD it declares.
- An automated test suite covering the shared navigation and registry behaviour.
- A Content-Security-Policy check that runs against the built output on every build.
Accessibility
Tool Fly is built to be usable with a keyboard, with a screen reader and at different screen sizes. We describe this as an intention we work towards rather than a certification we hold, because we have not commissioned a formal conformance audit.
One main heading and a skip link
Every page has a single first-level heading, and a skip link takes keyboard users straight to the main content instead of through the header navigation.
Keyboard reachable controls
Buttons, links, filters, the search field, the theme switch and the accordion questions are all reachable with a keyboard alone. The disclosure questions use native markup, so the browser handles the open and close behaviour.
Visible focus and a reduced-motion option
Focus is never removed without a replacement. Animations are reduced when the operating system asks for reduced motion, so the carousel and the transitions stop moving for anyone who has that setting turned on.
Text that survives a zoom
Layouts are built with relative units and flexible grids, so the page can be zoomed to 200 percent without losing content or forcing horizontal scrolling on the main column.
Labels that describe the control
Form fields have visible labels. Icon-only buttons carry an accessible name. Images that carry information are described; decorative images are hidden from assistive technology.
Where the limit is
We do not claim a WCAG conformance level for the site, because a conformance claim has to be backed by an audit of the real pages and we have not run one with an independent reviewer. The list above describes how the interface is built. If something is hard to use, we want to hear about it.
If something on this site is hard to use, the contact page reaches a person who can fix it. Tell us the page, the task you were trying to finish and, if you know it, the browser and the assistive technology you were using.
Editorial policy
The catalogue has more than two thousand written entries. These are the rules we hold ourselves to when we write them, so that a page describes the tool instead of selling it.
Describe the job, not the outcome you promise
A good description tells you what the tool does with your input and what comes out. It does not promise that the result is perfect, approved, professional or guaranteed.
Name the limit in the same place as the feature
A file limit, a format that is not supported, a rate that is a reference rather than a live feed, an inbox that does not receive real mail: these belong on the page of the tool they apply to, not in a separate policy nobody reads.
Never imply a certification we do not hold
There is no audit badge, no security certification and no compliance claim anywhere on this site. Those are things a project has to earn with evidence, and we would rather have none of them than a decoration.
No invented numbers
No testimonials, no star ratings, no "trusted by" logos, no visitor counts and no traffic figures. Where a number appears on this site, it is a count of the catalogue, computed from the registry.
Keep the legacy brand out
The project was renamed. The old name is replaced everywhere it used to appear publicly, in the interface, in the metadata and in the structured data, so that a reader is never left wondering which name is current.
What comes next
This is a working list, not a promise with dates. The order reflects what is already being worked on. Items marked as exploring are ideas, and ideas can change or be dropped.
In progress
One shared description of where the work happens
The processing badges are in place across the catalogue. The remaining work is to make sure the wording stays correct as tools are added, and to extend the shared privacy table on this page to every department.
Locales that have a real page behind them
Each language needs its own crawlable address, its own canonical link and its own set of alternate links, so a reader in one language and a search engine both know which page belongs to which language. Where a translation is not ready, the English page is the canonical one rather than a machine copy.
Planned
The same treatment for the department pages
Department pages get the shared question block and a matching structured-data block, so that the questions a visitor reads and the questions a search engine sees are the same questions.
Owner details, finally
The placeholders on this page are waiting for the facts only the owner can confirm: the legal entity, the team behind the project, the year it started, where it operates from and where the source lives.
Exploring
Optional account features
Browser-local profiles exist for convenience. An optional online account could add cross-device favourites and history. It is an idea, and it would change the privacy story, so it stays an idea until the privacy story is designed properly.
More tools for the departments that need them
Several departments are thinner than others. The next additions are chosen by what people actually ask for in the contact inbox, not by what would make the catalogue look bigger.
Languages
The interface is translated into the languages listed below. The written copy of a tool page is currently written in English, and a translated interface does not change the canonical language of that page.
- EnglishEnglish
- हिन्दीHindi
- FrançaisFrench
- DeutschGerman
- اردوUrduCurrently selected
Why the list is short
A language is only added when the whole chrome of the site — navigation, buttons, headings and help text — can be read properly in it. A partly translated page is harder to use than an English page, so we would rather add a language slowly.
Who is behind Tool Fly
The facts in this section are the ones the project cannot verify on its own. They are written down as placeholders rather than filled in with a plausible guess, because a wrong legal name or a made-up founding date is worse than an honest gap.
8 details are still waiting for the owner. They are marked below and are not published as facts.
- Legal entity or registered business name
- TODO — add the legal entity or registered business name Waiting for confirmationThe registered name of the person or company behind Tool Fly. Write "Not a registered business" if that is the case.
- Who builds and maintains Tool Fly
- TODO — add the name of the person or team behind the project Waiting for confirmationA name, an initials, or "An independent project". Do not add a team size that cannot be verified.
- Year the project started
- TODO — add the year the project started Waiting for confirmationThe year work on Tool Fly began. Use the year the first tool shipped if that is clearer.
- Where the project is based
- TODO — add the country or region the project operates from Waiting for confirmationCountry or region only. A full street address is not needed and is not wanted here.
- Support hours
- TODO — add the hours when the contact inbox is checked Waiting for confirmationFor example "Replies are sent within a few working days". There is no guaranteed response time.
- Public source repository
- TODO — add the public repository URL, or "The source is not published yet" Waiting for confirmationLeave it unpublished if the code is not meant to be open. Do not point at a repository that does not exist.
- Public profile
- TODO — add a profile link, or "No public profile yet" Waiting for confirmationA profile the owner controls. This is the only place a social link may appear.
- Who decides what gets built next
- TODO — add how roadmap decisions are made Waiting for confirmationFor example "Requests in the contact form are reviewed by the maintainer".
Questions people actually ask
These are the questions that come up most often about where the work happens, what is stored, what is not, and who is behind the project. The answers describe the project as it is built today, so they change when the code changes.
Do I need an account to use Tool Fly?
No. Every tool in the catalogue opens as a guest. A browser-local profile and an optional cloud account exist for people who want favourites and history, but nothing in the tools themselves requires one.
Where does my file actually go when I use a tool?
For a browser-side tool, it stays in your tab. The tool reads the file in browser memory and hands the result back to the page, so there is no upload and nothing for us to store. Each tool card and tool page shows a badge that says which case you are in.
Which tools use your server?
Two of them. The link preview tool asks our server to read a web page, because a browser cannot read a page that blocks cross-origin requests. The AI assistant answers locally by default, and sends your prompt through our server to a model provider when you choose a model. Both are marked "Uses our server" or "Uses our server for some steps".
Is the "runs in your browser" claim really true for every tool?
No, and that is exactly why the badges exist. Most tools do run in the browser, and those show "Runs in your browser". The two exceptions are marked as such, on the card, on the tool page and in the privacy table on this page.
Do you have testimonials, ratings or user counts?
No. We do not have verified figures for any of those, so they are not on the site. The numbers you see here count the catalogue itself — how many tools exist, how many run in the browser, how many departments there are — and they are computed from the tool registry.
Is Tool Fly accessible?
It is built with keyboard support, screen reader labels, a skip link, a single main heading per page and a reduced-motion option. We do not claim a formal WCAG conformance level, because that claim needs an independent audit we have not commissioned. If you hit a barrier, please tell us which page and what you were trying to do.
What happens to my data in local storage?
Preferences, favourites and drafts are kept in your own browser profile, not on a server. That means they stay on your device, they are not synchronised anywhere else, and anyone with access to that browser profile may be able to see them. Clear the site data from your browser settings to remove them.
Are the exchange rates in the currency converter live?
No. The converter uses a reference rate table that ships with the tool and is reviewed by hand. The page shows when the table was last reviewed. Treat the figures as estimates and check a live source before you rely on them for a payment.
Does the temporary email tool receive real email?
No. It creates a disposable address and keeps a practice inbox in your browser tab, with a refresh every twelve seconds and messages shown in a sandboxed frame. It does not connect to a mail server, so use it to rehearse a sign-up flow, not to receive a real verification code.
How are the tools in the catalogue tested?
The registry validates every tool record when the application starts, the build pre-renders every page and checks its title, canonical link and structured data, and an automated test suite covers the shared flows such as search, department filtering and the Back control.
Why are there so many calculators?
Because a calculator is the shortest path to a useful answer: you type two numbers and you get a number back. The collection is counted from the registry, so the number on the page is the number of calculators that exist right now.
Can I request a tool or report a problem?
Yes. Use the contact form in the footer of any page. It is helpful to include the department, the name of the tool, your browser and a short description. Please do not send passwords, one-time codes, payment details or confidential files.
Will a tool keep working if I clear my browser data?
The tools themselves will still work, because the work happens in the page. What you lose is the browser-local extras: your favourites, your drafts, your saved palettes and your local profile. Download anything you want to keep before you clear your browser data.
Who is behind Tool Fly?
That detail is still a placeholder on this page, on purpose. The facts about the owner — the legal entity, the team, the year the project started and where it operates from — have to come from the owner rather than from an assumption, and they are marked as pending until they are confirmed.
Contact, corrections and requests
If a tool does not do what its page says, if a description is wrong, or if you need something that is not here yet, the fastest route is the contact form in the footer of any page. It reaches the same inbox as the address below.
Please include the department, the name of the tool, your browser and a short description of what happened. Do not send passwords, one-time codes, payment details or files that contain confidential material.
Report a problem
Use the contact page and choose the topic that fits. A description of the tool, the input you used and what you expected to happen is usually enough to reproduce the issue.
We read every message. There is no guaranteed response time, and we will not pretend there is.
Request a tool
Requests go to the same inbox. A useful request names the task, the format you work with and the tool you would use today instead. Requests that arrive with that detail are the ones that get built.
The questions page answers the questions that come up most often, which saves both of us a round trip.
Start with any tool
There are 2,664 tools in the catalogue and 2,662 of them do their whole job inside your browser. The other 2 tell you before you use them that they need our server. Open one and see for yourself.