Twitter Photo Card image url has mysterious inscrutible constraints


Hi there. I made
which is a little toy that lets you turn a 16x16 bit of pixel art into a URL that you can then tweet. I

A while back I added twitter cards support for the photo card, so that you could preview the pixel art inside twitter. It works by generating png files on my server, on the fly, based directly on the contents of the png’s filename. ( decoding it as base64url )
I validated and was approved and whitelisted, using twitter’s validation tool. I’ve been whitelisted for a while. It’s been great.

My experience so far is that twitter cards are quite fickle, and the validator will report “invalid card type” for any problem having nothing to do with the validity of the card type meta tag. I thought I was clever to figure out in the beginning that twittercards will only accept an image of a certain minimum size. So I now blow up my 16x`16 pictures to 1024x1024 for the benefit of twitter’s image proxy.

But now I’ve hit a brick wall. I thought I had broken twitter cards in a recent update. but I didn’t. Twitter cards will work with some of my urls, but not others, and the reason for the breakage seems directly related in some way to the number of Alpha characters in the image url.

so for instance, a blank white pixpe works just fine

and a certain amount of alpha characters will work too

right up to this amount. 91 alpha characters after the /

but then one more A, and this doesn’t work, 92 alphas: "invalid card type"

replace them mostly with 0’s and it works

replace with 9’s, and it works

a pixpe made entire of 9’s works

but this one, with the same amount of 92 Alphas’s, broken up in the middle by underscores, does not work. invalid card type

I can detect no obvious difference in my server’s response. The html it produces is just a simple substitition: the image url is the same as the html url but with .png on the end. (and the second letter replaced with a “D” for “jumbo twitter size picture, please”). There’s no weird regex mistake on my end, the html you get from every one of these urls is the same, except for the url itself in the meta tags. It’s the twitter card validator. There is some limitation it has on what is allowable as an image url, and I just can’t work out exactly what it is. The only workaround I can think of is providing a special URL format just for twitter cards that contains only number characters. Maybe that will make the twitter card gods happy.


One issue could be that your robots.txt file actually goes to a page rather than rules that our crawler can read. (

Be sure to check out some information here:


Thanks for the tip. I’ve fixed that. But sadly adding a robots.txt has had no effect on which URLs are considered valid. by your validator.


Just took a look at your meta tags and I’m noticing application meta tags without values. If these are included, they cannot be left empty otherwise the card throws an error. For example, the meta tags at the URL below should be filled in or removed.


noted and fixed. though if those are a problem the card validator should not haver told me to add them in the first place.

in any case, the working and non working state is still directly related to the number of alpha characters in the image url.

we might want to look at why that is. or at least what the rules on that url are meant to be so i don’t waste time on a workaround that won’t work.


in fact, if you include the httppixpe characters at the start, the number seems to be exactly 100-
if you have 101 alpha characters, the validator says "invalid card type"
if you have 100 alpha characters, you’re okay, but 101 or more, anywhere in the URL and it is invalid. Exactly. Predictably. Like there’s some kind of validation step that counts the number of alpha characters.
isn’t that interesting? Isn’t 100 an intriguingly round number to be so predictable?


It is interesting indeed. Our logs show that we cannot figure out the character encoding of your page. Could you add to your HTML? That could possibly fix your issues.


Pow. That’s fixed it!
and still curious exactly why that’s the solution, and why it’s exactly 100 characters? Maybe that’s some kind of internal counter limit where the bot has decided it can’t figure it out.


It is an interesting coincidence. I’m not sure why it only worked up until 100 characters, but I’m glad everything is good now!