Twitter Header Safe Zone Guide — one upload, several crops
An X (Twitter) profile header is uploaded as a single image and then shown as several different ones. The desktop profile, the mobile web profile and the native apps each take a different slice of the frame at a different aspect ratio, the profile avatar is composited over the lower left of it, and interface chrome sits over parts of it as well. That is why a header that looks balanced in an editor so often arrives with a wordmark cut in half on a phone: the editor showed you the whole rectangle, and no surface ever displays the whole rectangle. This header safe zone guide draws each crop over one frame and shows what they have in common.
The safe area is an intersection, not a box you can look up
Because each surface crops differently, there is no single safe zone to memorise. The area that appears intact everywhere is the geometric intersection of every crop — the region inside all of them at once — and it is always smaller than any individual crop. Content placed low and to the left may clear the desktop crop and still be swallowed by the avatar in the app; content placed near the top may survive in the app and be cut away on desktop. Only the overlap answers both questions at the same time.
Turning a crop off recomputes that intersection immediately, which is the point of the tool rather than a convenience. Isolating a single surface answers what does the phone app actually show?, and switching the others back on shows what it costs to clear them too. When the enabled crops do not overlap at all, the tool says there is no common area rather than drawing a box with a negative width.
Crops shrink the safe area; obstructions cover it
The two kinds of region on the canvas do different things, and the distinction is worth keeping straight. A crop is a viewport’s visible slice, so it takes part in the intersection. An obstruction — the avatar disc, a back arrow, an overflow menu — is drawn over the header on a surface that still shows the rest of it, so it never shrinks the intersection. It is painted as a hatched exclusion on top instead. Treating the avatar as a crop would quietly shrink the reported safe box everywhere, including on surfaces that do not draw an avatar at all.
Fractions of the frame, never pixels
Every region here is stored as a fraction of the uploaded frame, with the origin at the top left. A header renders at whatever width the viewport happens to be, so a crop measured as 600 px on one display is a different number of pixels on every other one, and a stored pixel figure is right on exactly one device. Fractions survive that rescale, and they survive X restating its nominal upload size. The tool converts to pixels only at the moment it draws or reports, which is why the readout gives the safe box both as an x, y, width, height rectangle at the frame’s stated reference resolution and as percentages for tools that work proportionally.
Your image stays on your device
Loading a header image is optional — the geometry lesson works on the placeholder frame with nothing loaded. If you do load one, it is decoded by your browser, drawn onto a canvas on this page and encoded back into a file your browser saves locally. There is no server to upload to and no field for an image address, because a remote image would taint the canvas and break the export outright. Files are checked against both a size cap and a megapixel cap, since a small compressed file can still decode to an enormous bitmap, and a rotated phone photo is turned upright from its orientation tag before anything is drawn.
A header that is not the frame’s aspect ratio is not rejected. It is fitted to the frame and the empty bars are marked, because seeing how much of the frame a 16:9 source cannot fill is usually more useful than being told to resize it.