In short
An event can be given an upload link that guests use to send you their photographs and video. They do not need an account, an app, or a login. Everything they send arrives held back, and nothing appears on the event page until you approve it.
The behavior to understand before you print that link on a table card is what happens to a file the platform will not take. It is discarded quietly. A guest who sends nine photographs and one unsupported file is told the upload succeeded and never learns the tenth was dropped. Only when every file in a submission fails does the guest see an error — so a partial loss is invisible to both of you unless you go looking.
On this page
The guest link
Each event has its own upload address, carrying a token that belongs to that event alone. The link is the whole credential — anybody holding it can contribute, and nobody without it can. That is deliberate, and it is what makes the link printable on a place card, a sign at the door or the back of a menu.
Because the link is the credential, treat it as one. It is not secret in the sense of a password, but it is not public in the sense of an address you would post: anyone who has it can add to your event’s queue.
Event pages have their own address separately from the upload link. Older events created before addresses were named will quietly repair themselves the first time somebody visits — the page mints its proper address, saves it, and forwards the visitor on. Anything printed with an old link keeps working.
Turning collection on and off
Guest uploads are off until you switch them on, and switching them off closes the door properly rather than just hiding it. The setting is checked twice: once when the page is opened, and again when a file is actually sent.
That second check is the useful one. A guest who opened the upload page an hour ago and has been choosing photographs since cannot send them after you have turned collection off. Their upload is refused at the moment they press send, not accepted because their page was loaded while the door was open.
What guests can send
| Limit | Value | What happens at the edge |
|---|---|---|
| Files per submission | 20 | The whole submission is refused with a clear message |
| Size of one file | 100 MB | That file is dropped. The rest go through |
| Photographs | JPEG, PNG, GIF | Anything else is dropped. The rest go through |
| Video | MP4, MOV, AVI | Anything else is dropped. The rest go through |
File extensions are read without regard to capitals, so a photograph named with a capitalized extension is accepted normally — a common worry with files straight off a camera, and not a real one.
Note the asymmetry in that third column. Sending too many files is the only limit that tells the guest plainly what went wrong. Every other limit fails one file at a time and says nothing.
The files that vanish
This is the single most important thing on this page. When a guest submits a mixed batch, each file is examined on its own. Files that pass are stored. Files that fail on type or on size are skipped, and the process moves on to the next one without recording a complaint anywhere the guest can see.
The success message is then written from what survived. If anything at all made it through, the guest is told their files were uploaded successfully. The message does not count them.
If a guest insists they sent a photograph you cannot find, believe them. The likely explanation is that it was a format the platform does not accept — a photograph straight from a recent iPhone in its native format is the usual culprit — and neither of you was told. Ask them to re-send it as a JPEG.
Nothing appears until you approve it
Every submission arrives pending. The event page shows only your own media and the guest submissions you have approved, so there is no window in which something unwanted is publicly visible and then removed. Approval is the publishing step, not a tidying-up step afterwards.
Approved media is shown newest first, so a submission you approve during the event appears at the top of the page rather than buried at the bottom.
Approval works on the whole submission
One trip through the upload form produces one item in your queue, however many files it contained. Approving it publishes all of them; declining it publishes none. There is no way to approve nine photographs from a submission and hold back the tenth, because the decision is recorded against the submission rather than against the individual files.
This has a practical consequence at events where you expect to curate. Ask guests to send in small batches, or send one at a time, if you are likely to want anything other than all-or-nothing. Twenty photographs arriving as a single submission is twenty photographs you must accept or refuse together.
Names, captions and what you can rely on
Guests may give a name and an email address, and may caption each file. All of it is optional and none of it is verified. A submission with no name attached is normal and is not a sign of anything having gone wrong.
Captions are matched to files in the order they were chosen. In practice this is reliable, but it is worth knowing that the pairing is positional rather than attached to the file itself.
The original filename a guest sent is kept with the record even though the stored file is renamed to something unrecognizable. If you need to trace a particular photograph back to whoever sent it, the original name is the thing to look for.
Who gets told, and when
| Who | Told when | What they are told |
|---|---|---|
| You, the event owner | Every time a guest submits | How many files arrived, and that they need reviewing |
| Event subscribers | When media is approved | That there is something new to see |
| The guest who uploaded | Once, immediately | That the upload succeeded and you will review it |
Anyone can subscribe to an event with an email address. Subscribing twice does nothing and creates nothing — the second attempt is answered politely and ignored. Somebody who unsubscribed and later changes their mind is restored rather than added again, so unsubscribing is never a one-way door.
Symptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| A guest’s photograph never arrived | Its format or size was rejected and nobody was told | Ask for it again as a JPEG under 100 MB |
| Fewer files arrived than the guest sent | The unsupported ones were dropped one by one | Compare counts; ask the guest to re-send the missing ones |
| “Maximum 20 files allowed” | More than twenty in one go | Split into two submissions |
| “Guest uploads are disabled” after the page loaded fine | Collection was switched off between opening and sending | Switch it back on if the event is still running |
| Approved media is not on the event page | Looking at the wrong event, or the approval did not save | Re-check the queue; approved items publish immediately |
| Only part of a submission should be published | Approval covers the whole submission | Not possible. Ask for smaller batches next time |
| An old printed event link goes to a different address | The event repaired its address on first visit and forwarded | Nothing to fix. Old links keep working |
Things people commonly get wrong
Related reading: Secure upload, Uploading media, Requesting a print, and When something is not working.