Resize an image to 512 × 512
The 512 × 512 box is preset: the page scales your artwork or photo onto that exact square and writes the file in your browser — JPG is the default, and the format bar takes PNG if the destination wants losslessness.
Your images
Settings
Set both for an exact pixel size; set one and the other scales to keep the ratio.
Generated images
- Nothing uploaded
- Free, no sign-up
- Strips EXIF
- Batch files
512 is the square that store shelves, app grids and profile rails all standardize on. The app store build wants a 1024 master and derives the smaller tiles itself, the store listing page asks for a square thumbnail somewhere around 300 to 512, and the avatar column on every platform you have ever used renders at some pixel count that started as a 512 square in a designer's hand. The file you have is usually a marketing render — 2000 × 1500, a banner, a photo shot wide — and the question is how it becomes the square the system wants without a design tool open for thirty seconds.
This page is that thirty seconds. The box is locked at 512 × 512 and the format bar opens on JPG, which is what listing pages and most upload forms accept. A square source arrives unchanged in proportion; anything else fills the box, and that is the one decision the page cannot make for you — see the crop-first note below if your artwork is wide.
One file or a folder of variants — light and dark versions, platform variants, a client's full brand set — queues in the same way and leaves as one .zip, in the order it arrived. All of it happens on your machine; the master file in your project folder is the pixel-identical file it was a minute ago.
How it works
The box and the format are already set; the only real choice is whether the composition survives the square.
Add the artwork
Choose the file, drop it on the page or paste with Ctrl+V. A 1024 × 1024 master is the ideal source — the same mark, twice the pixels to average from. Banners, product renders and photos all work; a 2000 × 1500 render will fill the 512 box by squashing the bottom, so wide pieces should be cropped square first.
Square it, then set the format
If the source is not 1:1, press the crop button on the card: a center-locked square frame opens over the image, drag it to put the part of the artwork that matters in the middle, and the 512 × 512 output then carries that composition. The format bar defaults to JPG — pick PNG if the upload form lists lossless formats, or if the square has a transparent or near-transparent background that survives losslessness better.
Generate and take the file
Press Generate images, check the result in the Compare slider at the size it will actually render — an app icon at 512, a web avatar at 96 — and download. A batch of platform variants comes back as a single .zip in queue order, ready to drop into a handoff folder.
Where 512 × 512 shows up in the wild
The exact square travels between tools and platforms; here is the list that will actually ask for it:
- App store and Play listing icons: the master is 1024, the intermediate 512 square is the standard thumbnail size in most listing UIs
- Podcast cover art: Apple Podcasts and Spotify accept larger, but 512 is the preview size every client renders — if it does not read at 512, it does not read at 3000
- Avatar and profile rails: most platforms store at 512 or 720 and scale down; a 512 export is the smallest honest square
- Marketplace seller photos: Etsy, eBay and print shops render thumbnails in that range and cap per-listing file weight
- Game and app tiles in Windows, macOS and Android settings that sample a 256 or 512 square from the master
Filling a box is a composition decision
A 3000 × 3000 cover arrives exactly right. A 2000 × 1500 render does not: the tool stretches the pixels to 512 × 512, and the result is an icon that is shorter and wider than the artwork was designed to be. The page cannot guess the subject, so the honest path is to make the guess yourself — the crop button on the card opens a 1:1 frame, you center it on the logo, face or product, and the 512 output then carries that crop instead of the squashed original. This is the same advice the 64 × 64 page gives, at a size where the squashing is less visible but still there.
JPG or PNG at 512 — the format bar decides
The page opens on JPG because listing pages, store dashboards and e-mail attachments all accept it, and a 512 px photo encodes to a few hundred kilobytes with no visible loss. Switch to PNG when the destination is a web page that cares about weight, when the artwork has hard edges or text that JPEG's ringing would soften, or when the background is transparent — JPG has no alpha, and a cutout on a transparent board will come back with a white rectangle behind it. PNG at 512 lands in 1 to 3 KB for a simple icon and up to 300 KB for a photographic one; both are fine on any modern upload form.
Batching a brand set
The usual job at this size is not one icon, it is a set: primary and reversed marks, light and dark UI variants, a podcast cover and its square crop, an app icon and its masked version. Queue them in the order the handoff document expects — the .zip preserves it exactly — and the folder on the other side of the e-mail lines up one for one with the spec. The quality slider is off the table for a PNG batch; for a JPG batch, 82 is the default and fine for every icon use.
- Order survives the round trip, so the .zip lands in the same sequence as the queue
- A 1024 master scaled to 512 loses almost nothing visible; a 400 px source mapped onto the box stretches to fill it and reads soft — the honest fix is a larger master, since no detail is invented for the gap
- HEIC sources decode on-device (about 1 MB one-time fetch) and join the queue like any other file
Frequently asked questions
My icon is 400 × 400. What happens if I run it through the 512 box?
The box is literal, so the 400 × 400 source stretches onto all 512 pixels and the card will show 512 × 512 — but no detail is invented for the missing 112 pixels, and the result reads soft against a crisp store-rendered neighbor. The honest fix is a larger master from your design file; if the 400 px is all you have, deliver it at 400 or redraw the mark, rather than shipping a soft 512 that the store thumbnail will only make look worse.
Why did my 1600 × 900 banner come out looking squashed?
The box is a literal 512 × 512: both dimensions fill it, and a 16:9 source mapped onto a 1:1 box is shorter and wider than it was drawn. Crop the banner to the square that contains the logo or face (the 1:1 crop button on the card), then generate — the page will then shrink the square, not stretch the banner.
I need 512 for an app store that also wants 1024. Do I run this page twice?
The 1024 master is the one the store actually ingests; 512 is the thumbnail size in the listing UI and the preview size in every podcast and app client. If you already have the 1024 master, you do not need this page for the store upload — use it for the 512 thumbnails, the avatar set and the listing-page squares, and both files come from the same master, which keeps the two visually identical.
Does a transparent background survive a 512 JPG?
No — JPG has no alpha channel, so any see-through corners come back filled white. Pick PNG on the format bar and the transparency is part of the output. For a solid-background artwork, JPG is the lighter, better choice and the transparency question does not arise.
Is 512 enough for a podcast cover, or do I need 3000?
Both, and they are different jobs. The 3000 × 3000 master is what the podcast platforms ingest and downscale; the 512 square is what listeners actually see in the client's art column, and it is where a cover that was designed at 3000 reveals text that is too small to read. Make the 3000 first, then drop it onto this page and judge the 512 preview — if the title is legible there, the cover will read on a phone.
Does the file leave my computer?
No. The decode, the square mapping and the JPG or PNG encode all run in your browser on your machine. The master on disk is not modified, and there is no upload step to wait on or to fail — that is the whole point of the page existing.