Editorial Team

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

Owns the words on every tool page and guide: drafts the on-page steps, the framing-menu sentences, and the FAQ answers; trims phrasing that drifts from what the tool actually does; signs off readability across reader skill levels.

Editor - Tool Engineering Lead

Owns the code path: reads the live tool end-to-end before the page ships, traces every reader-facing claim back to the frontend pipeline or the backend service class, and clears the technical accuracy of each instruction step.

Editor - Quality & Cross-Device Review

Owns the cross-device check: reads the staging page on phone, laptop, and external-monitor sizes; confirms each control responds and each download lands; clears the page for the Last reviewed stamp before it goes public.

The three roles read each other's work before anything ships. The content lead drafts and the engineering lead reviews the live tool; the quality lead reads the staging page on phone, laptop, and external-monitor sizes and confirms each control responds. The bookkeeping is plain: every tool page and guide carries a Last reviewed date, and that date only moves once all three editors have signed off on the change.

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

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

Tool pages render as plain static HTML and ship the same code to every reader. When two readers disagree about a claim - "does HEIC preserve EXIF?", "can the browser play this MP4 codec?" - the editor settles it with the source-of-truth ladder named above: the file format public specification first (ISO 32000 for PDF, ISO 23008-12 for HEIC, ISO 14496-14 for MP4, PKWARE APPNOTE for ZIP), then official browser-vendor release notes, then the open-source engine source. The named editor who last reviewed the tool page owns the resolution.

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?

The editorial work runs on a public per-cycle cadence: every cycle is a dated folder in the development repository carrying the SEO analysis, implementation plan, and verify-and-ship log together. A reader who wants to see what changed scans the folders by date and reads the per-cycle plan plus the matching progress log. Cycles run one to two weeks.

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.

The Editorial Team page lists three named editor roles and the work each one owns. If you arrived from a tool footer credit or a corrections link and want a one-screen answer, the named role descriptions sit directly above, the layered review schedule sits two sections up, and the contact route for corrections is linked at the foot of the page. Every paragraph here is published under the Editorial Team byline; nothing on this page is anonymous.

This page is called Editorial Team, and the title is also the shortest answer to "who edits the words on the tools you are using". The page lives at this URL so a reader who clicks through a tool footer credit or a corrections link lands on a one-screen answer: who reviews the on-page steps, what cadence the review runs on, and where to send a correction when an instruction no longer matches the live page.

Need to know who stands behind the site you are reading? This page names the three editorial roles - words, code, and cross-device review - and ties each one to a concrete commitment. Every tool page carries a dated review credit that traces back to the editor who last checked it; if a claim or a screenshot no longer matches what you see, the named editor is the right person to flag through the contact form.

The Editorial Team page names the three pre-publish checks every new tool page and every guide runs through before it ships: an accuracy review against existing pages, a real-browser test on phone and laptop in current Chrome, Firefox, Safari, and Edge, and a staging read-through on a copy that is not yet public. The contact route at the foot of every page is how readers send corrections back to the named editor who last signed off.

A reader who scans the search snippet, a tool-page footer credit, or a corrections link sees the page title verbatim - two words, fourteen body characters - and that title is meant to carry the answer on its own. The body of this page explains the three editor roles, the pre-publish checks, and the layered review schedule for the reader who has more than a glance to spare; the reader who only had time for the title leaves with the answer to "who reviewed this".

In short, the page name is meant to answer its own main question without anyone needing to read further: "Editorial Team" tells a reader who scans a tool-page footer credit or a corrections link who reviews the on-page steps. The body below is here for the reader who wants more - the named role each editor owns, the layered review schedule that keeps tool pages current, the pre-publish checks every new tool page and guide runs through before it ships, and the contact route to flag a correction when an instruction stops matching the live page.