Editorial Team

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

Read the principles

• Browser-first where possible; server-side when needed. Lightweight tools (developer utilities, device tests, simple converters) run inside your browser. Heavier tools that need native binaries (HEIC decoding via libheif, ffmpeg / ImageMagick command runners, PDF flatten / merge / split / preflight, video conversion, image optimization with SlimJpg) upload over HTTPS to our processing service, run server-side, and the files are removed shortly after. Each tool page documents its own data flow in plain words.
• 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

Editor - Content & User Experience Lead

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 per-tool architecture: tools that can run client-side do; tools that need a native binary (HEIC, ffmpeg, PDF preflight / flatten / split / merge, video conversion, image optimisation) upload over HTTPS to our processing service and the file is removed shortly after. Works most on: video converter, FFmpeg online, and the MD5 converter.

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

Read the two commitments

• Per-tool truth-source for data handling. Each tool's privacy posture matches its implementation: tools that can run client-side do (developer utilities, device tests, simple format checks); tools that need a native binary (HEIC, ffmpeg, PDF flatten / merge / split / preflight, video conversion, image optimisation) upload over HTTPS to our processing service and the file is removed shortly after. The first FAQ answer on every tool page states which model that tool uses.
• 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:

Read the review schedule

• 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 the queries that brought visitors to the site.
• 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:

Read the 3 pre-publish checks

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:

Read the sources we verify against

• 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. Lightweight tools run entirely as browser applications. Tools that need a native binary (HEIC decoding, ffmpeg / ImageMagick command runners, PDF flatten / merge / split / preflight, video conversion, image optimisation) upload over HTTPS to our processing service, run server-side, and the file is removed shortly after. The full source code is public, so anyone can verify each tool's actual data flow against the code itself rather than having to take our word for it.

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.

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?

Meet the Free Tool Online editorial team the way a reader should: engineers who ship the tools, content specialists who write the instructions you follow, and security reviewers who vet anything that touches your files. We still publish dated plans and shipped-work logs in the open repository so curious readers can see what changed on the site and when—without wading through spin.

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

Behind the scenes, the site is reviewed on a layered schedule: reader-reported issues are triaged the same day, one tool category is checked each week, the full catalog gets a pass every month, and a full visual check across screen sizes (phone to external monitor) runs every quarter. If an instruction no longer matches what you see on the tool page, send the URL and its “Last reviewed” date through the contact form so the right editor can re-check that tool family.

Before a new tool or guide goes live, we run the same three checks every time: we cross-check instructions for accuracy and repetition, we test the page in current browsers on both phone and desktop, and we do a final staging read-through to make sure the on-page steps match what you see. If something reads wrong, it doesn’t ship until the underlying claim is traced back to the file format spec, the browser docs, or the library the tool runs on.

If you run into a broken tool or an instruction that doesn’t match what you see on the page, report it through the contact form with the URL and a quick note about what happened. Security reports (for example, something that leaks file contents or serves a dangerous download) are acknowledged within 24 hours, and routine accuracy reports are triaged within 72 hours so the right editor can re-check the tool.

How the editorial team is structured, in one line: three role-based editors — a Content & UX Lead who writes the on-page instructions, a Tool Engineering Lead who owns the code that actually runs each tool, and a Quality & Cross-Device Review editor who opens every page on phone, tablet, and desktop before publishing. The team runs a layered review schedule (same-day reader reports, weekly tool-category passes, monthly full-catalog sweep, quarterly visual check) and a three-step pre-publish process (accuracy and repetition check, real-browser test on Chrome / Firefox / Safari / Edge, staging read-through). The shipped-work log is public so curious readers can see what changed on the site and when.

The shape of the editorial team in five facts: three role-based editors, a layered review schedule, a three-step pre-publish check on every page, a public progress log of what shipped and when, and a written corrections policy that only appends — never silently overwrites. Each of the three role descriptions below names a concrete outcome a reader can hold us to: the Content & UX Lead is accountable for the words on the page, the Tool Engineering Lead for the code that runs the tool, and the Quality & Cross-Device Review editor for the way each page renders on the screen a reader actually opens it on.

Four practical reasons a reader can trust what they read on this site: every tool page is owned by a named editor with public accountability for the words on it; every page carries a dated review and ships on a weekly, monthly, and quarterly cadence so claims do not silently rot; every factual statement is traced to the file format specification or the open-source library the tool runs on rather than rephrased from another site; and AI drafting tools are disclosed where they assisted with outlining or repetition checks, but every paragraph is read end-to-end by a human editor before it goes live.

Who runs Free Tool Online resolves to four anchors. The editorial team — engineering, content, quality — meets weekly to triage in-flight tool work, monthly to walk every guide page against its source specification, and quarterly to retire any claim that no longer matches the live implementation. The source-of-truth ladder ranks format specifications above vendor documentation above open-source engine code, in that order, on every disputed claim. AI is treated as a drafting assistant only; every published paragraph is read end-to-end by a named human editor before it goes live, and any AI-assisted draft is flagged in the commit history.