Custom thresholds

When should you use Not clipped by Gmail?

email-gmail-clip-size · functional · recommended

When should you use this check?

Run this on long campaigns, digest newsletters, and any template that has been edited by many hands over time — those are the sends that drift over the limit. It is worth including whenever open tracking matters to you, because clipping cuts the bottom of the message where the tracking pixel usually sits, so the send looks fine and quietly stops being measured. It reads the HTML source and needs no render, so it costs almost nothing to leave in a set.

When should you not?

Skip it for short transactional mail, which is nowhere near the boundary and will pass forever without teaching you anything. It is also not a general size or performance check: it answers one vendor-specific question about where Gmail draws its cut, so if your concern is total message weight including images, this is not measuring that. Senders whose audience is overwhelmingly not on Gmail get proportionally less from it, though the limit is close enough to other providers' practical limits to remain a reasonable proxy.

What does it inspect?

Gmail truncates a message whose HTML source exceeds roughly 102KB and hides the rest behind "View entire message" — taking the footer, the unsubscribe link and the tracking pixel with it. The HTML body must stay under the configured byte limit. See docs/EMAIL-GMAIL-CLIPPING.md.

What does a failure mean?

A failure means the HTML is large enough that Gmail will hide everything past its cutoff behind a "View entire message" link. What falls below the cut is the worst possible selection: the footer, the unsubscribe link and the tracking pixel. So a clipped send is simultaneously a compliance risk, because the opt-out is one extra click away and many recipients will not take it, and a measurement failure, because opens stop being recorded while the campaign appears to be performing normally.

What are the Standard defaults — and why?

One parameter carries the check: `maxHtmlBytes`, defaulting to `102400`. That number is the published target for HTML source size rather than a constant anyone has measured Gmail applying exactly — the real cutoff drifts with transfer encoding, so treating it as a hard line would be false precision. Using the published target as the threshold keeps the check honest: clearing it means you are comfortably inside the behaviour, not that you have found the exact byte where clipping begins.

How does an agent call it?

{
  "type": "email",
  "validations": [
    "email-gmail-clip-size"
  ]
}

Who governs the Standard?

Schemafirst.org publishes community-governed standards for digital QA. ArbiterQA is a sponsor and commercial licensee of those standards; citation does not mean Schemafirst operates ArbiterQA.

Schemafirst.org

Author ArbiterQA · Reviewed by ArbiterQA · 2026-08-14