ShareMaster link, or Windows shortcut?

.shurl and .url

Archiving replaces a file's contents with a pointer back to your storage, and leaves that pointer in the library under the original file's name. This page is what the pointer itself can be, in full: what each kind is as a file, where each one works and why, and what the choice costs you later. It is a separate question from what a click on one does.

Reads only. Nothing in SharePoint is changed.

On this page What it tells you How it runs What you need What it will not do Read next

What it tells you

BOTH ARE SMALL TEXT FILES, about 916 bytes, and both are named for the file they stand for with the extension added on the end: "Budget 2025.xlsx" becomes "Budget 2025.xlsx.shurl" or "Budget 2025.xlsx.url". The original name is never lost, which is how a restore knows what to put back.
NEITHER CARRIES A CREDENTIAL. Inside is a pointer and identifiers - where in your storage the contents went, which tenant, site, library and item it came from, its original name and size, and when it was archived. Anyone who opens one in Notepad learns where the file lives, not how to read it.
.shurl IS A MICROSOFT 365 FILE HANDLER. Your tenant is told during setup which application owns that extension, so SharePoint draws the ShareMaster icon on it and offers "Open in ShareMaster Archive". It looks like something rather than like a stray link.
A FILE HANDLER ONLY EXISTS IN A MODERN LIBRARY VIEW. In a library somebody has switched to the classic experience a .shurl is inert - not slow, not ugly: it cannot be clicked at all. Same in File Explorer on a synced folder, which is not a SharePoint view either. That is the one fact that rules this kind out, and there is no setting that changes it.
A click on one is not an ordinary web request. Microsoft 365 POSTs it to the action URL registered against your application - which is why it needs the registration, and why it works only where SharePoint itself is doing the drawing.
.url IS A NATIVE INTERNET SHORTCUT. Nothing has to be registered anywhere for one to work, which is exactly why it works in the two places the other kind cannot. A click is an ordinary browser request straight at the endpoint address written inside it.
A .url we write carries TWO sections. First [InternetShortcut] with the URL, which Windows and SharePoint already understand - some programs stop at the first section they recognise, so it goes first. Then ShareMaster's own section alongside it with the identifiers. Both name the same target, and a file whose two halves disagreed would be refused rather than written.
ShareMaster never registers .url as a file handler, deliberately. Doing so would claim every other shortcut in your tenant, and needing no registration is the entire point of this kind.
.shurl IS RECOMMENDED BECAUSE IT IS EASIER TO REVERSE. Putting a library back means finding our own placeholders among everything else in it, and that extension is ours - nothing else writes it - so the names on a list of rows are enough to find every one.
.url is a PUBLIC extension that SharePoint's own New ▸ Link produces, and so does anything else that makes a shortcut. One of ours can only be told from somebody's own by READING it, which is a round trip per candidate file instead of a name test - so a bulk restore over a large library takes materially longer. On the Archive options step there is a hidden-column setting offered only for this kind, for exactly this reason.
THE CHOICE APPLIES TO THE RUN you are setting up, not to the tenant. A later run can leave the other kind, placeholders already sitting in libraries keep working either way, and changing your mind re-registers nothing and restarts no clock.
IT IS NOT THE SAME QUESTION AS WHAT A CLICK DOES. Hand a copy back, or put the file back into the library, is recorded inside the placeholder and asked on its own step - either answer can be combined with either kind of file.

How it runs

Choose .shurl for a normal SharePoint site. People open the files in the browser, the library is on the modern experience, and you may want the whole library back one day. This is nearly always the right answer.
Choose .url for classic, or for Windows. The library is still on the classic experience, or people reach these files through a synced folder in File Explorer rather than the browser. In both places a ShareMaster link does nothing at all when clicked, so the trade is worth taking.
Not sure which experience a library is on?. Modern is the default and what a site uses unless somebody deliberately switched it. If the library's page looks like the rest of Microsoft 365 - the command bar across the top, the details pane on the right - it is modern.
Mixed estate? Run it twice. The kind is per run, not per tenant. Archive the modern libraries in one run and the classic ones in another, and each gets the placeholder that works where it lands.
Either way the original is not deleted. Its contents move to your own Azure storage account. Both kinds carry a pointer and never a credential, both keep the file's name, folder, permissions, item identity and version history in place, and both restore the same file.

What you need

For .shurl: the file type registered during setup, and Microsoft's 24 to 48 hour propagation finished. Until that window is up a click does nothing useful, on a placeholder that is otherwise correct.
For .url: an archive endpoint new enough to answer an ordinary browser request. Older endpoints answer only the file-handler POST, and the option is shown DISABLED with that reason until Create or update has been run on the endpoint step - shown rather than hidden, so nobody hunts for a setting that is merely out of date.
For either: your own archive endpoint reachable from wherever the person clicking is. The placeholder is only a pointer; the endpoint is what fetches the contents.

What it will not do

A .url carries no icon and no marking, so a library of them looks like a library of links. Nothing on the file itself says it stands for an archived document.
Archiving never touches a shortcut - .url or .lnk - because one only points at something else. So a later run over the same library skips the placeholders an earlier run left there, whichever kind they are.
A placeholder of either kind in a folder somebody syncs with OneDrive behaves differently, and that case is not covered yet.
RENAMING ONE BY HAND does not change what it restores as - the original name is recorded inside the file, not taken from what the placeholder is called. But changing or dropping the EXTENSION hides it from a bulk restore, which finds placeholders by that extension. A single file can still be put back by opening it.