Check a timer image before you send it
Paste the image address from your timer. This page reads it, loads the picture the way a mail client loads it, and shows you what came back. The address goes from your browser to that host and nowhere else.
Paste a timer image address
This loads the address in your browser, the way a mail client loads it, and shows you what came back. The request goes from you to that address and nowhere else. Nothing about it is sent to this site, and nothing is stored.
The image URL from the generator, from the publish screen, or the src of the timer in your template. An address on your own image domain works too.
What that address returned
What is in the address
The signature is the right shape, which is all this page can say about it. Whether it matches is something only the image service knows, and an address whose signature does not match is answered with the card reading "image unavailable" rather than with a countdown.
What each client is documented to do with an image like this
Three clients publish something about when they fetch a remote image and how much of it they play. Here is what each one says, with the document it says it in.
Documented, not tested. Every line above is what somebody else published, and no timer from here has been watched in a real inbox yet. When there are dated screenshots they will go on the email client pages and those pages will say so. Yahoo, AOL, Thunderbird and Samsung Mail publish nothing about any of this, so there is no line to print for them.
What a picture on this page can and cannot tell you
A timer in an email is an image, and the image is drawn at the moment it is fetched. That single fact is behind almost every question about these timers, and it is why a check that happens here is worth less than a message that arrives in a real inbox, and more than nothing.
What the box above settles is the address. A signed timer address has one shape: the host,
then /i/ and the template id, then .gif or .png, then
the workspace, the published version, an optional recipient token, an optional watermark
flag and the signature. Anything else was edited, truncated by a spreadsheet, or built by
hand, and the image service answers it with a plain card reading "image unavailable" rather
than a countdown. Reading the parts is also the only way to catch the failure that costs a
whole send: a merge tag such as
{{first_name}} still sitting in the address, because the
signature covers every parameter and a platform that fills one in after the address was
signed breaks it for every subscriber at once.
What it cannot settle is whether the signature matches. That needs the signing secret, which is on the server and is the whole reason a signed address cannot be edited by whoever has it. So an address of the right shape can still come back as the unavailable card, and when it does, the address is intact and the signature is not.
What each client does with the image, and where that comes from
The table above lists three clients because three is how many publish anything about when they fetch a remote image. Each row cites the document it rests on, and the page marks the whole table documented rather than tested, because no timer from here has been watched in a real inbox yet. That is an honest gap rather than a modest one: what is missing is dated screenshots from each client, and when they exist they will be on the email client pages with the build and the date beside them.
The short version, which the rows say at length. Outlook on Windows draws the first frame of an animated GIF and does not animate, so a subscriber there reads a correct, still countdown. Apple Mail with Mail Privacy Protection fetches at delivery, through an Apple relay, before anybody has opened anything, so the picture a reader sees was drawn when the message arrived. Gmail fetches through Google's own proxy on the first open and can serve a later open from the copy it already holds, and Google does not publish how long it keeps one. Yahoo, AOL, Thunderbird and Samsung Mail publish nothing about any of it, which is why there is no line for them rather than a guess.
When the picture is not the problem
Three things look like a broken timer and are not. A picture that loads here and shows a
time you did not expect was drawn at the fetch, and the fetch is the client's decision, not
yours. A picture that shows the design at zero with "Offer ended" under it has passed its
deadline and is working exactly as it is meant to. A picture with a faint mark across it is
the over-quota watermark, which the row above names when the address carries
wm=1.
What is worth chasing is an address that returns nothing at all, an address whose signature does not match, and a merge tag still in the query. The troubleshooting pages take each of those one at a time, and the merge tag reference gives the syntax each sending platform uses, which is where the tag in the query came from.
Where to get an address to paste
If you do not have one yet, the free countdown timer generator makes a real published timer in a browser and hands you the image address and the snippet, with no account. It will also send that timer to your own inbox once, which is the test this page cannot be. A GIF file you already have, from here or from anywhere else, is a different question, and the GIF checker answers that one: frame count, loop flag, palette and file size.
For a timer in an account, the address is on the publish screen next to the snippet. If your workspace serves images from your own hostname, that address is accepted here too, and custom image domains covers how it is set up.
Questions
Reading what came back
Five questions about this page, answered the way I would answer them in an email.
Does this prove the timer will work in a send
It proves two of the three things that can go wrong. It reads the address, so a missing signature, a merge tag the platform never filled in and a path the image service does not serve are all named before you send. It loads the picture, so an address that returns nothing is obvious. What it cannot do is check the signature itself: that needs the signing secret, which lives on the server. An address of the right shape whose signature does not match still loads here, and what comes back is the card reading "image unavailable" rather than a countdown.
Is the address I paste sent to you
No. The check runs in your own tab and there is no form here that posts anywhere. The one request the page makes is your browser fetching the address you pasted, from whichever host it is on, which is the request the page is about. Nothing about it is stored, and closing the tab is the end of it.
Why does the picture show a different time from my dashboard
Because a timer image is drawn when it is fetched. The picture on this page carries the time remaining at the moment your browser asked for it, and a picture in an inbox carries the time remaining at the moment that client asked for it. The two are different moments, and for Apple Mail with Mail Privacy Protection they can be days apart, because it fetches at delivery rather than at the open.
Have you watched these clients yourself
Not yet, and the page says so beside every line. What the table gives you is each client vendor’s own documentation, linked in the row, plus two vendor reports where nobody has documented the behaviour at all. Dated screenshots from a real inbox are owed and they will go on the email client pages, which will say when they were taken and on what build.
It says my address is on a custom domain
That means the host is not img.emailtimer.app. An Agency workspace can serve the same images from its own hostname, so a custom host is accepted and read exactly like ours. What this page cannot tell you from the outside is whose workspace that hostname belongs to, so it says that rather than guessing.