Sharing Code Not Working? 8 Causes and What Each One Means

You type five characters, press the button, and get nothing back — or worse, a message that tells you the code does not exist. It is the most common failure in code-based sharing, and almost always one of a handful of causes, each with a different fix. Guessing wastes more time than reading the response, because the response is specific: the server distinguishes between a code that is gone, a request it refused to accept, and a client it has temporarily throttled.

Read the Message First

Before touching anything else, read the exact text of the error. The wording maps one-to-one onto the failure, and each one has a different remedy:

The Eight Causes

1. The window closed

Codes are born with a countdown — typically ten minutes from the moment they are created, not from the moment you start reading them. If a sender generates a code, gets distracted, and comes back to read it on a second device five minutes later, the remaining window is five minutes, not ten. The sender's result screen shows the countdown running, which is the most reliable warning you will get.

2. Someone already opened it

Most short-code systems are single-use: the first successful retrieval deletes the content immediately, so every later attempt returns the same 'not found' message as an expired code. This is by design — it is what stops a leaked pointer from being fetched repeatedly. It also means the sender may have tested the code themselves, a curious colleague may have opened it, or you may have pressed Receive twice and lost the race against your own first request.

3. A character was misread

Codes are written to be transcribed: the alphabet drops I, O, 0, and 1 so that letters and digits cannot be confused. The look-alikes that remain are still worth checking — 2 against Z, 5 against S, 6 against G, 8 against B — especially when the code was read aloud over a call or copied from a photograph. Case is not the problem: input is normalised before lookup, so a lower-case entry is accepted. Length is: a five-character code that reaches the server as four will be rejected outright.

4. The code went into the wrong box

The send and receive flows look similar, and it is easy to paste a code into the content field instead of the receive field — or to stay on the Share Text tab when the content was sent as a file. Codes are direction-agnostic; the screens are not. Confirm you are on the Receive tab, that the code sits in the field labelled for entering a code from your other device, and that the content type matches what was sent.

5. The rate limit caught you

Retrieval is budgeted per address — on the order of twenty attempts a minute — and sending is budgeted tighter still, around ten a minute. A page stuck in a retry loop, a script polling for a code, or simply several rapid attempts while debugging can exhaust the budget in seconds. The limit resets on a rolling one-minute window, so waiting is genuinely the fix; mashing the button keeps the counter where it is.

6. The page went stale

A tab left open for hours runs yesterday's interface against today's service. If a request silently fails — the device lost Wi-Fi, a VPN dropped, the browser suspended the background tab — the page shows no error at all, because the request never completed. A hard refresh re-establishes the connection and usually clears it. If other sites work but this one does not, suspect the page before you suspect the code.

7. A network or proxy blocked it

Corporate networks, school networks, and some VPNs filter API traffic while leaving ordinary pages reachable. The symptom is a request that never returns — no error message, no spinner that finishes — on one network and works instantly on another. Switching to mobile data for ten seconds is the fastest way to confirm it. Nothing about the code changes; only the path to the server did.

8. The content was refused

Sometimes the code worked and the payload was the problem: text past the character ceiling (10,000 characters is a common limit), or a file that is too large or in an unsupported format. File transfers usually restrict both — for example to images and short videos under 10 MB — because anything larger needs a different transport altogether. The rejection happens on the send side, so the receiving device simply never sees a code to enter.

A 60-Second Diagnostic Sequence

Working through the causes in a fixed order avoids the common mistake of rebuilding the transfer when the actual problem is a single character:

1. Read the error text verbatim — 404, 429, and 422 each send you down a different branch, and only one of them is fixed by waiting.
2. Re-read the code from the sender's screen, one character at a time, checking it is exactly five characters long.
3. Confirm the receive box is selected and the code is in the code field, not the content field.
4. Wait a full minute, then press Receive once — this clears a rate limit and stops a retry loop from refilling it.
5. Refresh the page, then enter the code again, in case the tab was stale or offline.
6. Try once from a different network, such as mobile data, to rule out a proxy or firewall.
7. If it still returns 'not found', the key is genuinely gone — ask for a new code rather than retrying the old one.

How to Avoid It Next Time

• Send immediately before reading — generate the code when you are already on the receiving device, so the whole window is available to you.
• Use the copy button rather than reading aloud: the result screen has a one-tap copy, and a clipboard round trip beats any transcription.
• Scan the QR instead of typing when both devices can see each other — the code travels as a link and never passes through human eyes.
• Watch the countdown chip on the sender's screen; when it empties, the code is gone regardless of who did what.
• Split oversized content into two transfers rather than trimming it — a rejected send produces no code at all.

When It Is Not the Code

One distinction saves the most time: a rejection from the server means the request arrived and was judged, while silence means it never arrived at all. Errors are the server talking back — expired, throttled, malformed — and they resolve by getting a fresh code or waiting out the window. Silence is always local: a dead connection, a blocked request, a stale tab, a proxy in the path. Diagnose the channel first when you get no message, and the code first when you do.