Initializing, please wait a moment

Editorial Team

Last reviewed 2026-04-24.

Free Tool Online is built and maintained by a small team of editors. We write the instructions on every tool page, test every tool in the browsers you actually use, and check the privacy and security of anything that reads your file. This page is a straight answer to a fair question: who is behind the site, and why should you trust what you read here.

Editorial principles

  • Browser-first, no upload. Every tool on the site runs inside your browser. Your file (photo, PDF, video clip, audio, text) does not leave your device unless you explicitly ask for a share link. Each tool page says in plain words how it handles your file.
  • Answer first, depth second. Every tool page answers the question you came with at the top: what the tool does, the three steps to use it, and one concrete fact about how it handles your file. Longer explanations sit below the tool for readers who want the trade-offs.
  • Corrections are added, not hidden. When an article needs a correction, we add the new information below the existing paragraph and date it. Readers who bookmarked the page find what they remembered, plus the correction.
  • Dated reviews you can verify. Every guide and every hub page shows a review date. When a page is re-checked, the date moves. A date that never moves is not a trustworthy one, so we move ours.

Our editors

The site is run by four editors, each accountable to you for a specific part of what you see on every page. The composite titles below describe the role; each role has a concrete outcome a reader can hold us to.

Editor - Content & User Experience Lead

Twelve years writing help content for consumer software. Owns every paragraph you read on a tool page: the one-sentence definition at the top, the step-by-step instructions, and the FAQ at the bottom. If a tool's instructions are wrong, unclear, or miss a format you are trying to use, this editor owns the fix - and reviews each tool page for accuracy at least once a quarter. Works most on: PDF tools, image converters, and the device-test checklist for remote work.

Editor - Tool Engineering Lead

Ten years shipping browser-based applications. Owns the code that runs the actual tool - the part that converts your file, runs the microphone check, or hashes your text. Verifies every tool works in the current versions of Chrome, Firefox, Safari, and Edge before it goes live, and is responsible for the no-upload architecture: your file stays on your device because the processing runs inside your open browser tab. Works most on: video converter, FFmpeg online, and the MD5 converter.

Editor - Security & Privacy Reviewer

Eight years in application security. Owns the privacy promise. Before any tool that accepts your file goes live, this editor checks that the file stays inside your browser: no upload, no cookie carries your content, no analytics beacon includes anything from your input. Also flags what a tool leaves behind inside the file you download - EXIF tags on photos, author metadata on PDFs, comment fields on ZIP archives - so you know exactly what is in the output. Works most on: zip file, remove ZIP password, and flatten PDF.

Editor - Quality & Cross-Device Review

Seven years in front-end quality assurance. Owns the visual and functional check on every page before publishing. Opens the site on phone, tablet, laptop, and external-monitor screen sizes, catches broken layouts, and confirms that buttons, file pickers, and keyboard navigation respond the way they should on each device. If a tool looks off or misbehaves on your screen, this review is the first line of defense. Works across every page on the site, on every device class readers use.

Editorial policy

Our editorial policy is intentionally short and operational: we want it auditable in one screen, not buried across a policy PDF. The full workflow is described in the content-review process below; the two bright-line commitments are:

  • No upload by default. Every tool that can run client-side does run client-side. The exception is short-URL sharing, which is documented per-tool in the FAQ. If a tool needs a backend, the FAQ says so in the first answer.
  • No rewriting of published paragraphs. Corrections are appended, not silently overwritten. Readers who bookmarked a guide via a search result find the same answer they bookmarked, plus any newer addenda.

How often the site is checked

The site is on a layered review schedule so that no part goes stale:

  • Same day: Reader-reported issues (via the contact form) are acknowledged and triaged the same day they arrive.
  • Weekly: One category of tools (PDF, image, image converter, developer, device-test, video, utility, or ZIP) is given a full review - every tool in the category is tested end-to-end in the latest Chrome, Firefox, Safari, and Edge; every related guide is re-read for accuracy; every dead link is fixed.
  • Monthly: A pass over the full tool catalog. Broken tools are retired. New tools are proposed to fill workflows readers ask about in the contact form and in search traffic.
  • Quarterly: A full-site visual check on every common screen size - phone, tablet, laptop, and external monitor. Layout issues are logged and fixed before the next publishing window.

How we check content before publishing

Every new tool, every new guide, and every substantive edit passes three checks before it lands on the public site:

  1. Accuracy and repetition check. The new text is read against every existing tool page and guide to catch contradictions with something we said elsewhere and to remove repetition the reader has already seen on another page. Every factual claim (how a file format behaves, which browsers support it, what the tool's size limit is) is verified against the file format's public specification before publishing.
  2. Real-browser test. Every tool is opened in a real browser - current Chrome, Firefox, Safari, and Edge - at phone, laptop, and desktop screen sizes. We confirm the UI does not overlap or clip, the tool completes its job on a real test file, the Disable Ads button still works, and keyboard users can reach every control.
  3. Staging run. The change goes live first on a staging copy of the site, which is not indexed by search engines. An editor reads the staging page the way a first-time reader would. Only after the staging read passes does the change land on the site you are reading now.

What we base our answers on

When a tool page or a guide says "PDFs do X" or "HEIC can store Y", the claim has a source. We check each claim against one of the following before publishing:

  • The file format's public specification. The PDF spec (ISO 32000), the HEIF / HEIC spec (ISO 23008-12), the MP4 container spec (ISO 14496-14), the ZIP file format spec (PKWARE APPNOTE), and so on. If a format behavior is in the spec, we quote it rather than guess.
  • Official browser vendor documentation. What Chrome, Firefox, Safari, and Edge actually support today - which image formats they can decode, which video codecs they can play, which APIs they expose - comes from the vendors' own release notes, not from hearsay.
  • The open-source engines the tools run on. The site's image, PDF, audio, and video tools are built on public open-source libraries - libheif, libde265, libjpeg-turbo, poppler, pdf.js, ffmpeg.wasm, clean-css, terser, and others. Every tool page credits the library it uses so you can read the source code or the changelog yourself.

How the site is built

The site is delivered as plain static HTML pages. Tools run as browser applications - there is no server that sees the content of your file. The full source code is public, so anyone can verify the no-upload claim against the code itself rather than having to take our word for it.

For the background on why the site is built this way - the trade-offs, the cost story, the user-trust observations - read the case study what we learned running free in-browser image tools for 100K monthly users.

Questions we have been asked

Who writes the content on each tool page?

Tool pages and guides are written by the Content & User Experience Lead and reviewed for accuracy by the Tool Engineering Lead before publishing. Every guide and every hub page carries a short credit line under the title that names the editorial team and the last review date, so you can see at a glance how recently the page has been checked.

How do you decide what tool to build next?

Three inputs drive the roadmap. First, reader messages through the contact form - if multiple readers ask for the same workflow, that is a strong signal. Second, search-traffic gaps - patterns we can see in anonymous query data that suggest a workflow we do not yet serve. Third, file-format changes in the open-source libraries the site is built on, which sometimes enable a tool that was not practical before. Proposed tools are built on a staging copy of the site first, reviewed, and only then published here.

Is the content AI-generated?

Content is written by human editors who use AI tooling in the drafting stage (outlining, checking for repetition against existing pages, catching phrasing quirks). Every published paragraph is read end-to-end by a human editor who verifies it against the source specification or the tool UI before it goes live. We do not publish AI output without that review. AI is treated as a drafting assistant, not as an author.

Where can I read the editorial plan for the current month?

The site's public source repository includes a seo-reports/ folder organized by date. Each folder contains the plan for that period (what will change on the site, in what priority) and a live progress log (what has shipped, what is still open). These are the public record of what has been changed on the site and why.

How do I report a broken tool or a wrong answer?

Use the contact form. Include the URL of the page, what you expected to happen, and what actually happened. If the report is a security concern (a tool leaking file contents, a dangerous download, a phishing link in content), put "security" in the subject line - we acknowledge security reports within 24 hours. All other reports are triaged within 72 hours.

Explore the site

For the broader project mission and the story behind the site, see About us. For in-depth tutorials and decision guides authored by the editors above, browse the guides archive - 23 long-form guides as of 2026-04-24, each with an explicit dateModified. For a single-page index of every tool, guide, and resource on the site, see the site map.