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.

You can verify these editorial principles on any tool page yourself. The browser-first rule is visible in the first FAQ answer: tools that run client-side say so, while the ones that need a server-side native binary - HEIC decoding, an ffmpeg or ImageMagick run, PDF flatten, merge, split, or preflight, video conversion - say that instead and name what happens to your upload. The answer-first rule is just as checkable: every page leads with the answer you came for, and keeps depth and trade-offs second, below the tool.