Help
Yoink file link not working? Troubleshooting for receivers and senders
If a Yoink link will not open, work through three areas in order: the complete URL, whether the upload finished, and how your browser handles that file type.
Updated
Receiver checks: the link and the request
Open the exact, complete URL in a full browser, not just a chat app preview.
If the link still fails, ask the sender to copy the full link again and paste it carefully.
If you see a 404, a 403, or a network error, treat it as a clue, not a diagnosis. There is no rule that files expire after a set period, so do not assume the file simply timed out. Try another browser and a network you are allowed to use, and do not bypass workplace network controls or disable safety features to force a download. Receivers never need to sign in to open a public link.
A separate case is a file that downloads fine but will not open locally. Check you have free disk space, compare the downloaded file size with what the sender says it should be, and try an app that supports the format. A missing thumbnail or preview image is likewise not proof of a broken file; some files simply do not render inline.
Sender checks: the upload completed and the right link was shared
A link only works if the file behind it finished uploading. Yoink's flow allocates an upload URL first and then sends the file bytes to storage. Getting a link-shaped URL at the allocation step is not proof the bytes arrived; the interface only marks success after the storage upload returns a success response.
- Share the public file URL (the files.yoink.zip address shown after success), not the temporary upload URL.
- Confirm the upload showed as completed in the page before copying the link, and keep your original file for future use.
An empty My Files panel or cleared Recent Uploads history is not the cause of a broken link. Those lists live in your browser only, and removing entries does not delete the stored file.
Download vs preview behavior
Whether a link shows a file inline or downloads it is decided by your browser, based on the Content-Type metadata sent with the response, the Content-Disposition header when one is present, and whether your browser has a viewer for that format.
Yoink's normal upload flow passes along the content type supplied at upload time, but the legacy upload path does not set HTTP MIME metadata, and a wrong or missing content type makes browsers more likely to download rather than display. Codec and format support also vary: a video or audio file that plays in one browser may only download in another.
If you need a previewable version, ask the sender to re-export the file in a widely supported format, such as a standard image or PDF, and upload that copy. Do not just rename the extension; that changes the label, not the contents.
For developers
The upload and API details are documented in the docs. A 401 at the presign step concerns the sender's optional authentication. A 403 on the storage PUT needs checking against the upload request and signed URL; it is not a prompt for the recipient to sign in. If an upload attempt genuinely failed against a stale signed URL, start a normal new upload attempt to get a fresh one rather than retrying the old URL.
If it is still broken
Send the file's owner the exact browser you used, the exact error, and the time you tried. Keep the link itself out of public bug reports, since anyone with the link can open the file. If the hosted copy is not reachable, the sender's option is to re-upload the source file and share the new URL; there is no self-service restore or recovery feature.