Feedback for "Upcoming Changes to PNG Image Support"



How much information can you give about how to tell whether a PNG file will be recompressed based on a hypothetical JPEG version’s filesize?

I’m making a tool that allows users to optimize their art before uploading to twitter, by losslessly compressing it in optiPNG to see if it’ll come in small enough, and then offering to lossily compress it to 256-color in case that looks less bad than the eventual JPEG compression will.

But how are users supposed to know what approach to take? What good does an “if it’s smaller than the JPEG” clause do, if users don’t KNOW whether it’s going to be smaller than a JPEG whose settings we don’t know? The only way to learn what approach to take is to have already posted the image and seen what filesize it gave once it was online in front of everyone.

I know you said you don’t want to say in case the settings wind up changing, but I can tell you now, on February 11th I’m going to upload a test file, then look at the result in exiftool, and base my script on whatever it gives, and so will anyone else trying to deal with this vague rule that we’re depending on, so you may as well tell us what the initial settings are going to be, rather than making us scramble on the day the change goes live to find out the same information the hard way.


Just to be clear: I’m aware of the “85% quality” figure, but I’ve gotten very different filesizes out of the same “quality” setting in different programs, according to things like 4:4:4 vs 4:2:0, etc…

Can you give us a few example files to compare against, to at least identify a way to locally compare results before the day that the switch is thrown?


Really great questions, @RavenWorks. I really appreciate that you are trying to work within the boundaries to make new tools to benefit all users.

First, I think the easiest thing to do is, if the image has 256 colors or less, just automatically convert to PNG8. I would like to work with the team to make that more automated on our side. For now that is just an idea and so external tooling doing it would make sense until I can make the case internally.

Using something like optiPNG or oxiPNG is a great idea, I like that a lot. It cannot scale internally, but moving that onto the user’s computer makes it much more likely to be viable.

For comparing between JPEG to see if it meets the threshold, I will share the specifics of our internal codec – however, that is entirely subject to change (as you’ve noted) and I cannot guarantee it will persist. The threshold could itself end up changing too (hopefully to be more permissive). In any-case, the closest match you can get is the following:

  • libjpeg-turbo codec
  • progressive encoding
  • 85% JFIF quality
  • 4:2:0 chroma subsampling

I hope this helps with tooling you might want to develop, but it doesn’t really come with guarantees. It should be pretty good though.


Thank you so much! :slight_smile: That’s definitely a helpful starting point. Do you think there would be public announcements somewhere if it were expected to change in the future?


That’s a fair question, @RavenWorks, but I’m afraid not. The public communication has been intentional to preserve areas that are subject to us making changes for the benefit of the platform, and it would be untenable to try to couple that to public announcements/documentation. I hope there could be a way, perhaps with the media upload Twitter API, to detect when changes do happen for developers that are concerned enough, but I can’t make any promises for communications.

If you ever are wondering if something changed though, you are free to contact myself (@NolanOBrien) or @andypiper and we can see about finding out. I’m sorry if that’s not a great dependency to have, but I want to be transparent to set expectations.


That’s alright, thanks anyway! Maybe I’ll just make a script that uploads a test image and compares the resulting file once a month or something…


@NolanOBrien thanks for getting back to me.

I believe this link should be accessible to you:

I downloaded and it was the same size in Finder as the original image, 2.9 MB.

I also tried attaching this image to a tweet via the Twitter desktop UI and publishing. It failed. Assume this still happens with the API, too.


@cstesto, thanks for sharing. I can reproduce the issue which means our engineers should be able to debug it. I’ll file a bug report right away. Thanks!


Is there a particular time of day planned for the changeover?


Good question. The rollout will take a while and will likely roll out in phases throughout the week. Today (Feb 11th) will mark the first phase and a subset of users and image categories getting moved over. We hope to complete the transition by the end of the week, but it might take longer. I’ll comment on the announcement once it has completed.


hey there! it’s me from earlier in the thread, i just wanna say i’m happy with the compromises made.

particularly, i am very interested in avatars being left alone. that has been a big point of contention for me since avatars started being compressed years ago. but i have a concern - will this change apply to tweetdeck, as it did before?
currently, my icon looks a LOT worse on tweetdeck than it does on web twitter, i’m not sure how tweetdeck handles icons, since it uses different sizes, but here’s a visual comparison anyway;

i believe that my web twitter is still compressing avatars, but tweetdeck just looks horrendous in comparison. do you know if the changes will affect tweetdeck or not? i wrote this at 12:18pm PST roughly. thanks!

EDIT: just to clarify, tweetdeck changed to compressing avatars when web twitter did. im not sure how linked the two are, but yeah!


The avatars on all platforms should properly reflect the change. If you have any issues once the transition is completed, please feel free to let me (@NolanOBrien) or @andypiper know.


Nolan, are you sure you don’t run a PNG optimizer? I just twitted a small (47040 bytes) animated PNG8 and it turned into a smaller (1377 bytes) static PNG8 file. Sad.


I could be mistaken on this (apologies if so!) But I do not believe animated PNG has ever been a supported format, so I’m not surprised that this converted to something static. I’ll need a co-worker to confirm that the expected behaviour, but it is certainly what I would expect to see.


Andy is correct. Animated PNGs are not supported. By happenstance the format for animated PNG can be decoded as a single frame and Twitter will support that, transcoding it into a new static image file which will be smaller in size than the animation.


hi there - just wanted to come back and say that the change has been applied to avatars for me. they’re now in perfect quality, and it’s awesome. thank you guys!


Hmm. I don’t think you need to do anything to support it, just don’t remove the frames. All modern browsers support APNG, so I suspect it will “just work” for most users.