TL;DR
- A MEGA link has two halves. Everything before the # is sent to the server. Everything after it is never transmitted at all.
- The half after the # is the decryption key. Without it the stored data is ciphertext and stays that way, which is why a keyless link is not a broken link.
- The design has been live since 19 January 2013, and a 2022 analysis from ETH Zurich reported five distinct attacks against it, four of which the authors described as eminently practical.
- Folder keys and file keys are different objects. A folder key decrypts the listing; each file inside still carries its own key.
Short version: the key is not a password guarding the file. For practical purposes it is the file. The rest of the URL only says where the ciphertext is parked.
Most people meet the MEGA decryption key at the worst possible moment: a link arrives, the page loads, and instead of a download button there is a box asking for a key nobody sent. The instinct is to treat it as a fault and start retrying. It is not a fault. It is the system working exactly as designed, and understanding why changes how you handle shared links from then on. It is also the reason a metadata index such as Meawfy can describe what is inside public folders without ever holding the contents: it was built by a single developer running crawlers against public links continuously, keeping names, sizes and structures in a database so a search returns useful description rather than a locked door.
Anatomy of a MEGA link
Strip a share link into parts and the architecture becomes obvious.
| Part of the link | Reaches the server? | What it does |
|---|---|---|
| The host name | Yes | Routes your request to the right service |
| The path, naming file or folder | Yes | Tells the server which encrypted blob to hand over |
| The node identifier | Yes | Addresses the specific item, and reveals nothing about it |
| Everything after the # | No | The key. Held by your browser, used locally to decrypt what arrived |
That last row is not a policy promise, it is how the web is specified to behave. RFC 3986 section 3.5 is explicit that the fragment identifier is separated from the rest of the URI before the request is made, and is processed by the client rather than sent as part of the request. The browser keeps it. The server never sees it, and cannot log what it never received.
Why the key sits there and not in a password box
The alternative designs are worse in ways that are easy to miss.
Put the key in a query string and it lands in server logs, in proxy logs, and in the referrer header of every outbound click from the page. Put it behind a login and the host now holds something that can decrypt your files, which defeats the point of encrypting on the client in the first place. Put it in a separate channel and you have solved nothing technically, you have only moved the problem to whichever chat app you used.
The fragment is the one component of a URL that is both easy to copy and structurally invisible to the server. That is why it carries the key.
The trade is real and it is not free. A key in the URL is a key in your browser history, your bookmarks bar, and every message where the link was forwarded. Anyone who reads it holds the file. There is no revoking a key that has already been pasted into a group chat, which is the practical weakness of the scheme and it has nothing to do with the strength of the cipher.
Folder keys are not file keys
This is where most confusion starts. A folder link carries a key that decrypts the folder’s index, meaning the names and structure of what is inside. Each file within that folder is encrypted separately and carries a key of its own, derived and delivered as part of the listing your browser decrypts.
Two consequences follow. Sharing a single file out of a shared folder produces a different link with a different key, not a sub-address of the first one. And a folder link whose key is intact will show you a complete listing even when individual files inside it have been removed, which is exactly how a link can look healthy and still deliver nothing.
When the key is right and it still fails
A decryption error has a small number of real causes, and they are worth telling apart before you ask anyone to resend anything.
- The fragment was truncated in transit. Chat clients, forum software and email wrapping all cut long URLs. A key short by a few characters fails identically to a wrong key.
- The link was shortened. Some shorteners drop the fragment entirely, because as far as they are concerned it was never part of the address.
- The content is gone, not locked. A valid key against a removed node fails at a different stage, but the message the user sees is often just as vague.
- The key is for a different item. Copying two links in a row and pairing the wrong halves is more common than anyone admits.
Worth noting that client side encryption is not the same as proven security. The 2022 paper MEGA: Malleable Encryption Goes Awry, by Backendal, Haller and Paterson at ETH Zurich, set out five attacks against the platform’s key handling and argued that four were eminently practical against a compromised or malicious server. The key in the fragment protects you from a passive log. It is not by itself a guarantee about everything upstream of your browser, a distinction that matters as much for organisations moving records into cloud tools as it does for individuals, and one that runs through the accessibility case for cloud based tools too.
What this means when you are searching
Because the key never reaches the server, nothing on the host side can index what is inside a share. The platform genuinely cannot search its own public content, and that is a property of the encryption model rather than a missing feature.
Anything that does describe public folders is therefore working from links that were already published openly, reading the metadata that a folder key exposes, and storing descriptions rather than contents. It is a narrower job than it looks, and it is the only job the architecture permits.
So the next time a link arrives without its fragment, the correct response is not to retry and not to report the file as dead. Go back to whoever sent it and ask for the whole URL, characters after the hash included. The file is fine. The half of the address that makes it readable simply never left their machine.
