Twitter has changed the rules for avoiding compression in uploaded art; the pixel trick doesn't work any more. :(
Under the new rules, there are three ways to try and avoid compression—but unlike the pixel trick, they can't necessarily always be applied; you might just have to accept the jpg compression! But luckily, these new tricks often work for art with a flat coloring style or a low resolution, which were the two art styles that are hit worst by jpg compression... so if you can't get exempt from the compression, there's a decent chance your art style didn't need it anyway. (No guarantee though, sadly...)
Twitter's new rules are:
Option 1 -Twitter will compress your art as a PNG file and a JPG file—and if the PNG comes out smaller, it'll use that.
PLEASE NOTE, this option has changed at the last minute! Originally, TwitImageFix v2 was going to help you losslessly optimize your PNG to improve its chances, but it turned out that Twitter's server always re-encodes any PNGs it receives, which throws away all of the optimization and makes it big again... I found out about this at the last minute, so I'm still working on rewriting this feature to instead just tell you whether your PNG is likely to pass Twitter's compression or not. In the mean time, it will just skip this test (it's not likely to pass anyway) and instead go straight to Option 2:
Option 2 - 256-color PNGs will always be allowed to stay PNGs.
The thing to understand about this option is that in attempting to qualify, TwitImageFix MIGHT ACCIDENTALLY MAKE YOUR FILE LOOK WORSE! If you don't qualify for Option 1, it will instead generate a 256-color version to qualify under Option 2, and this might look great or it might look awful, depending on the art. It will show you a comparison of what it did, with a prediction of how much of a difference it made, so be sure to look at the result and make sure it's still okay. If your art is pixel art, or binary pen art, or uses mostly flat colors with very few gradients, you might just get a basically-lossless file that will look much better than the JPG compression would; hooray! But if your art has lots of colors with lots of shading, it will probably look much worse than the JPG would, and you'll be better off just uploading the original and letting it get compressed. Sorry, that's the way Twitter's new system works... but like I said, art with lots of shading is the kind of thing that normally doesn't look too bad under JPG compression; it's the really flat-colored stuff that this tool is meant to rescue.
Option 3 - If your PNG file fits within 900×900, it will always be allowed to stay a PNG.
Good news if you draw small: if both the height and the width are 900px or smaller, then just post the file on twitter as a PNG—you don't even need to use TwitImageFix! Personally, I wouldn't recommend shrinking your art just to fit in 900×900—a high-resolution JPG usually looks much better than a low-resolution PNG would... But if it's already small to begin with, like a doodle or some pixel art, then you don't need TwitImageFix for it at all. Just put your small PNG up as-is and it should be fine! So that's one improvement over the old rules, at least.
One last important thing—this tool will NOT work if you upload the result through the official Twitter apps for iOS or Android: they both automatically force your art into a JPEG when you upload through them, even if it should have been left alone. So if you're using this on your phone/tablet, you have to upload the result through mobile.twitter.com or through a third-party app, not Twitter's official apps! :(
Also, if you're hoping to upload a file from here as your icon or your header, that should actually work now (another improvement!) but I've been told that you might have to use mobile.twitter.com rather than the regular twitter.com in order for it to work (at least for the moment).
Why does Option 1 say "skipped"?
Please see above! Twitter changed the rules at the last minute and I'm still readjusting the script, sorry.
It says the webpage is unresponsive / slowing down my browser! Is that bad?
I'll be fixing that soon! In the mean time, that's normal, it's still working fine, just give it a minute. This new version is much slower unfortunately, and I haven't had a chance just yet to set it up so it won't lag the browser while it's processing.
What open-source software did you use to make this?
Good question! This version needs a lot more control over file formats than the original did, and so it uses several open-source libraries: OptiPNG.js for the lossless attempt, PZNTG and neuquant for the palettized attempt, and mozjpeg-js and tgajs for the jpeg reference point. Thanks to everyone for their contributions!
How did you learn about these new twitter image rules? Where can I learn more?
Are the files processed here being collected at all?
As with the old converter: this conversion happens entirely inside your browser, your files are not transmitted anywhere. (Except by you putting it on Twitter after this of course!)
Can I use this to prevent compression in my icon or my header?
Yes! :D That's one nice improvement with the new rules—the old pixel trick didn't work for icons and headers, but the new rules DO work for both! The only catch is, I've been told that the normal twitter.com website is buggy with this, and you might have to use mobile.twitter.com instead to get it to work.
I converted a file here, but it still wound up compressed!
That might happen if you're using the official Twitter app on your phone/tablet: the official app unfortunately always adds extra compression, even when you use this tool. If you're on a phone or tablet, you have to upload files from here through the mobile.twitter.com website (or use a third-party app) to avoid that compression. If it's still happening to you even though you didn't use a client with extra compression, then please let me know—it's possible that Twitter changed some of the settings that I'm comparing against, and I might need to update the script.
The 'result estimate' said the quality was good, but it looked awful! (Or vice versa...)
It's only a very rough estimate, done with a very clumsy algorithm that I came up with in a hurry, so it'll never be perfect; but if you've found an example that you think is obviously way way off, you can let me know and I'll see if I can take its characteristics into account in the estimate.
Why not add dithering to the palettized image?
If an image's palette is insufficient enough that dithering would make a visible difference, then at that point you're better off just letting twitter JPG-compress it. The 256-color mode is for images that already fit almost perfectly within 256 colors; by the time you'd want dithering, it'd be doing more damage than the JPG would. If you're really convinced that you want to put a dithered image on twitter, you're better off using a dedicated tool that would give you more control over things like the way it selects its palette, rather than a one-size-fits-all automatic converter like this.
This interface really isn't very good on tablets/phones...
You're right, sorry. I ran out of time to do a second interface before the new rules rolled out; hopefully I'll have a chance to clean it up a little for mobile at some point. I figure most people will be using it on desktop though (the old one didn't even have a mobile interface for ages), so hopefully this is still better than nothing.
Are there any other features coming soon?
Yes! I really had to put this live before it was 100% finished; here's what I plan to change soon: