Six Slots and a Queue: What Actually Happens to a Photo After You Upload It

Our own safety library has a homework assignment it never graded. One guide tells you to “check whether the app confirms it removes EXIF data” — the metadata bundle, including GPS coordinates, that phones embed in photos. Another notes most major apps strip it, “however, not all do.” Fair advice — and until today, no page on this site confirmed anything about this app. So here is the missing page: what actually happens to a photo between the moment you pick it and the moment a stranger sees it on your card, written from the code path rather than from a promise. Some of it is reassuring, some of it is just strange, and one part — the six slots — does not work the way the grid makes it look.

The Gauntlet: Four Checks, in an Order That Might Surprise You

When the file arrives at the server it runs a fixed gauntlet: first the file extension (.jpg, .jpeg, .png, .webp, or .gif), then the declared content type, then the photo count — six per account is a hard ceiling, with a plain “Maximum 6 photos allowed” if you're full — and only then, after reading the whole file, the size limit of 10MB. Your browser also pre-checks before sending, but not the same list and not in the same order: it checks size first and type second, and never looks at the extension. The overlap between the two checklists is exactly one gate. None of this matters on a good day; it's here because “what gets rejected, and when” is the part of any pipeline nobody documents.

The Re-Encode: Everything Becomes a Fresh JPEG

Here is the single most consequential fact in this article: your original file is never what gets saved. Every accepted image — whatever format it arrived in — is decoded, processed, and written out as a brand-new JPEG under a random, machine-generated filename. If either side is longer than 1,200 pixels it's scaled down first (aspect ratio preserved); smaller images skip the resize but not the re-encode. And a freshly written JPEG contains only what the writer puts into it — and this writer puts in pixels, nothing else. We verified that the blunt way: we ran the exact production routine, on the production server, against test photos deliberately loaded with camera metadata and a GPS block. Output metadata, in both the resized and non-resized branches: empty. GPS block: empty.

So the answer to the safety guides' question is yes — with an honesty note attached. The metadata doesn't survive because the save step writes none; there is no “strip EXIF” feature with a product manager and a guarantee. It's a byproduct of the re-encode, which means it's behavior, not policy — true today, verified today, and stated here as exactly that. Keep following the safety guides' advice everywhere else you share photos; on this one surface, you now know what the pipeline does instead of hoping.

The same re-encode has three side effects worth knowing before you upload. Animated GIFs become stills — the format is accepted, but only the first frame survives, silently. Transparency becomes white — a PNG with a transparent background is flattened onto a white one. And — the one that actually bites — the orientation tag is dropped, not applied: if your phone stored a portrait shot as sideways-pixels-plus-a-rotation-instruction, the instruction is discarded with the rest of the metadata, and the photo can land sideways. If an upload comes out rotated, that's why; rotate the image itself before uploading and it won't recur.

The Six Slots Are Actually a Queue

The photo grid draws six numbered boxes, which quietly implies six addressable parking spaces. The storage underneath is nothing of the sort: a photo always lands at the end of the line. Position is assigned by count — your third photo is position 3's occupant regardless of which empty box you clicked — and when you delete one, everything behind it shuffles forward so the line stays gapless. A hole in the middle of your grid is not a state that can exist. The one thing the box you click does control: uploading through the first slot marks that new photo as your main photo. That is also, currently, the only way to change your main photo — there's no reorder control and no “make this my main” button, so the practical recipe is: want a new main? Upload it through slot one. Deleting your main photo isn't a crisis either — the first photo in the remaining line is promoted automatically.

What the System Actually Keeps

The database row behind each photo stores five things: the file's address, its place in your queue, whether it's your main photo, a verified flag, and when it was uploaded. That's the whole record — no original filename, no dimensions, no size, and no moderation state, because the upload path contains no review step. No human looks at your photo, and no automated screen scores it; the pipeline is validate, re-encode, save, done. (Moderation on Intently is report-driven — if someone reports a profile, humans get involved — but nothing inspects a photo at upload time, and we'd rather tell you that than imply a reviewer who doesn't exist.) About that per-photo verified flag: nothing in the product sets it. Verification on Intently is account-level — a government-ID badge on the person — never a stamp on an individual photo. If you ever see a product claim “verified photos,” that's not us.

And where does the finished JPEG live? On a plain static file server, at a URL built from that random machine-generated name. We probed the honest edges of that design on the live server this morning: a request for a made-up filename answers 404, not “log in first” — meaning photo URLs are unguessable but not authenticated. Practically: nobody can enumerate their way to your photos, but anyone who has a photo's URL can load it without an account. That's the standard trade almost every consumer app makes for speed, and you deserve to know it's the one we make: treat your profile photos as things a determined person could keep, because on every platform, they are.

What to Do With All This

Three practical moves fall out of the mechanics. Lead deliberately: the front of your queue is your discover card, so upload your best photo first or re-upload it through slot one. Pre-rotate: if a portrait shot lands sideways, the orientation metadata was the casualty — fix the pixels, not the tag. Stay metadata-hygienic anyway: this pipeline leaves EXIF and GPS behind as a byproduct of its re-encode, verified on the production path — but your photos travel to more places than Intently, and the safety guide's advice to strip metadata yourself remains the right habit everywhere it's your finger on the upload button.