Skip to content
FrameSafe StudioBETA

How we verify specs

Trust is the product. This page explains where every rule comes from and how sure we are about it.

Evidence classes

AOfficial requirement
Official requirement. Stated as a requirement on the platform's or publisher's own page. A verified one can fail a file.
BOfficial recommendation
Official recommendation. The platform recommends it. Breaking it gives a warning, never a fail.
CMeasured from official template
Measured from an official template. Safe zones measured pixel by pixel from the platform's own template files, with the script and output kept on record.
DBest practice
Best practice. A standard or common practice, such as EBU R 128, that you can choose as a target. Never shown as a platform rule.
EUnverified
Unverified. Only third-party sources, or sources that disagree. Hidden unless you turn on Show unverified, and never used to pass or fail a file.

How a value was verified

Read directly means we read the official page and kept a dated excerpt. Measured from the template means we measured the official file with a committed script. Supplied by the owner means the official text was provided to us verbatim. Anything else, such as a search excerpt, is shown as Not verified and can at most warn.

How the Checker decides

Your files are read in your browser: MediaInfo reports the container, streams, dimensions, frame rate, scan and bitrates, and a small reader checks MP4 and MOV files for fast start and edit lists. Each rule then gets a status. A verified official requirement that isn't met is a Fail; a recommendation, or a requirement we haven't verified, is a Warning; anything the file can't tell us is Can't verify, never a guess.

How the HTML5 Validator decides

The ZIP is opened in your browser, and checked for safety before anything else: zip bombs, paths that escape the folder, links and damaged archives are refused, and archives inside the ZIP are listed but never opened. The HTML, JavaScript and CSS are then parsed, never run, to find the entry file, the click implementation, every file the ad loads, and its weight on each basis a publisher uses. Weights from the code are estimates: files named only in scripts, or loaded from other servers, can turn a Pass into a Warning but never into a Fail. Anything the code doesn't settle, such as obfuscated click code, is a Warning. Rules that need the ad to run, such as CPU load and animation length, are listed as not checked until the runtime check arrives.

How values are compared

Aspect ratios match exactly, allowing only for pixel rounding (1080 × 1349 is 4:5), unless the platform states a tolerance, which then widens the check. Durations are compared at 0.1 s, because containers add a few tens of milliseconds of padding. Sizes in MB are read the stricter way, as 1,000,000 bytes, and we say so when a file falls between the two readings. Loudness is compared as it's displayed, at 0.1 LU. Ad copy, card counts and captions aren't part of the file, so those rules are listed as not checked from the file.

Safe zones

Zones are stored as fractions of the frame, so they scale to any size. Where a platform publishes template files (TikTok, Google), we measure the transparent area of the file. Covered areas may be hidden by the interface; they aren't forbidden.

Loudness meter

The meter passes all 29 EBU Tech 3341 and 3342 minimum-requirements cases that can be synthesised, at 48 kHz and 44.1 kHz. A frequency sweep matches the filter published in ITU-R BS.1770 to within 0.0014 dB, and its readings agree with two independent meters.

Keeping specs current

Every value carries the date it was verified. We re-verify each one at least every 90 days, and the changelog lists every change.

What a result means

Ready means the file matches the documented technical rules as of the verification date. It doesn't guarantee approval: platforms and publishers also review content and policy.