Twitter post image resizer — 1600 × 900, no cropping surprises
Produce a 1600 × 900 image for a Twitter or X post, matching the 16:9 preview the timeline actually renders, so your image is not cropped on the card.
Drop files here, or
JPG, PNG, WebP, AVIF, HEIC, GIF, BMP up to 50.00 MB · up to 30 files
Processed on this device — nothing is uploaded
Add a file to begin
How to use twitter / x post resizer
- 1Add your photograph or signature. A phone photograph taken straight above a signature on plain white paper works well.
- 2The specification is pre-loaded: the exact pixel box, the byte window, the format and the required background colour.
- 3Run it. The image is centre-cropped to the required aspect ratio, scaled to the exact pixel box, composited onto the mandated background, then compressed into the byte window.
- 4Read the result card, which states whether the output is inside the window and by how much.
- 5Download and upload. Keep the file — you will need the identical image again at document verification.
Why this tool, and why browser-side
Specification failures cost candidates entire application cycles. The portal names neither the pixel size nor the byte window when it rejects a photograph, so the only reliable route is to produce a file that is unambiguously inside the spec before you start.
The numbers are recorded here with their source and revision date because boards change them between cycles. Where a specification is our transcription rather than an official figure, the page says so.
Keeping the specification out of the user's hands is deliberate: you should not need to know what a 1:1.29 aspect ratio is to apply for a job. The pipeline applies it and explains what it did afterwards.
The frame here is 1600 × 900 pixels — an aspect ratio of 1.78:1 — which is the geometry this destination actually renders. Getting the ratio right is what stops an uploaded image being cropped by the platform after the fact, and it is why the tool crops rather than stretching the content into the box.
Pixels, DPI metadata and physical print size are distinct. For example, 35 mm at 300 pixels per inch is approximately 413 pixels, but pixels alone cannot guarantee a printer produces a 35 mm image. If the instructions also require DPI metadata or a measured print, check those separately.
On a phone, memory is the real constraint rather than any size limit. A 12-megapixel photograph is about 36 MB once decoded into pixels, so compiling a batch of twenty and holding every result in memory at once will get a mobile browser killed well before it runs out of storage. Process batches of ten to fifteen on a phone; on a laptop the same job is unremarkable.
Accepted inputs are JPEG, PNG, WebP, AVIF, HEIC, GIF and BMP images up to 50 MB each. SVG, HTML and other script-bearing formats are refused outright rather than sanitised, because a file that can execute code has no business being re-encoded — and an upload field that accepts one is a security hole rather than a feature. Output is written as JPEG, matching the format the destination expects. Several files can be queued where the workbench supports it. Batch, page and memory limits apply; check every output.
How it works under the hood
The pipeline is deterministic and ordered: decode while honouring the EXIF orientation tag, centre-crop to the mandated aspect ratio, resample to the exact pixel box with progressive halving to avoid aliasing, composite onto the required background colour so transparency never renders black, then search the encoder quality inside the byte window. Where a portal enforces a minimum size a clean signature cannot reach naturally, spec-legal inert bytes are added — a JPEG comment segment or a PNG text chunk, both of which decoders skip. Not one pixel is altered by that step. Photo presets fit the selected pixel box; signature presets preserve the whole mark with padding where needed. Transparent areas can be flattened onto white, but the tool does not remove an existing background. A byte window may be impossible, so check the result card and the official instructions.
Frequently asked questions
Why 1600 × 900 specifically?
Because that is the box the destination uses, and a different shape gets cropped or letterboxed without warning. The tool centre-crops to this ratio, then scales to exactly these dimensions so nothing is stretched.
Why is the output JPEG?
Because that is the format the destination accepts, and upload widgets read the file header rather than the extension — a renamed PNG still fails. The encoder writes a genuine JPEG file.
What if the portal rejects a file that matches these numbers?
Two common causes. The portal may re-encode your upload, pushing the byte count over the ceiling — aim for the middle of the window rather than the maximum. Or the specification was revised after this page was written; every page links to the official notification.
Can I use one resized file for several exams?
Keep the full-resolution original and export a separate file per examination. Requirements differ enough that one file rarely passes two portals, and you will want the matching copy at verification.
Why must the photograph and signature be separate files?
Because most portals validate them independently and reject a combined image. Where a form genuinely asks for a single sheet, the photo-and-signature joiner exists for that case.
Does the tool crop or pad my photograph?
It centre-crops to the required aspect ratio, because padding a portrait photograph to a different ratio leaves visible borders that many portals reject. If your subject is off-centre, crop it deliberately first.
Why is my output slightly under the minimum KB?
That happens when the compression lands just below the floor. The engine pads with inert bytes in that case, so the file reaches the minimum without any pixel being altered.
Does it strip EXIF from my photograph?
Yes. The output is freshly encoded, so GPS coordinates and camera identifiers are removed — which is what you want for a photograph of yourself, plus a signature strip.