Windows XP and later support symbolic links. Yet, Windows continues to use shortcut files (which essentially store the location of the linked file as text). Why?

  • 25
    Why do new versions of Windows (and Office) save text files in ANSI format and not UTF-8? Either to perpetrate incompatibility and unreasonability or to support legacy systems... Feb 2, 2016 at 5:52
  • 9
    Windows XP and later support symbolic on certain filesystems. Symbolic links work on an NTFS file system on your hard disk, but don't work if copied to a normal FAT 32 formatted USB stick, or a UDF format CD-ROM, and may not work if copied to a network server (as you often don't know the OS or file system used by the remote server). LNK shortcut files can be happily copied and work across all of those.
    – GAThrawn
    Feb 2, 2016 at 10:50
  • 12
    Windows .lnk files are more similar to Linux .desktop files than to symlinks. Feb 2, 2016 at 13:18
  • 3
    Symlinks are tricky security wise (confused deputy problem) Feb 2, 2016 at 16:01
  • 2
    So, did you stop using bookmarks in your browser when NTFS came around? It may sound like an absurd comparison, but only if you think that shortcuts are nothing but pointers to files - that simply isn't the case.
    – Luaan
    Feb 2, 2016 at 16:22

3 Answers 3


A number of reasons, I guess

  1. You can store different levels of compatibility against several different shortcuts to the same EXE as they're interpreted by the shell, rather than the file system.
  2. Certain shortcut links don't actually exist on the file system. Some of them are simply references to GUIDs, or special strings interpreted by the shell.
  3. You can't include switches in a symlink. You can point to the EXE, sure, but you can't tell that EXE any further arguments.
  4. You can't choose an icon for a symlink.
  5. You can't choose what directory to work from in a symlink.
  6. Shortcut files don't just have to point to files, they can be hyperlinks or protocol links (In the case of a .URL file).
  7. LNK files can exist on any file system. Symlinks are handled by the file system itself, in the case of Windows, NTFS.
  8. There's no real need to replace them. They work, they're tiny, they can be scaled up in the future should there ever be a need for more functionality to be added to them than listed above.
  9. Administrative rights are required to create a symlink (For good reason - otherwise redirection of innocent files to malicious ones can be executed with very little work)

There will be more reasons than this, but I think that's enough to get you started :) - There's a link provided by @grawity here that will give some further reading on parts of this topic.

  • 2
    Additionally, file shortcuts cache certain metadata about the target, and being interpreted at shell level allows shortcuts to be updated by the shell if the target has been moved, which would be harder with symlinks. In general, see Old New Thing again for various interesting things on shortcut features. Feb 2, 2016 at 6:03
  • 5
    @grawity Would there be any major benefit to moving these to being handled by the file system though? I would have thought .lnk files have an infinite room to expand for further functionality if required, whilst still retaining backwards compatibility, and they've not got a lot of overhead to them. Moving this to the file system would be a little over-engineered, perhaps? I'm by no means an expert on the inner workings of file systems, though.
    – Jonno
    Feb 2, 2016 at 6:13
  • 3
    True, the FS itself would have no use for most of this information – many .lnk features are really Explorer-specific, so storing everything as a reparse point instead of a file would be overkill. Feb 2, 2016 at 6:17
  • 3
    Just wanted to point out, LNK files can't, as far as I know, be used to target URLs (hyperlinks). You can use the same shortcut creation facility in Windows to create a shortcut to a URL, but the end result is a .URL file (which is plain text, essentially an INI file), not a .LNK file (which is binary). Feb 2, 2016 at 20:18
  • 3
    Or start http://superuser.com which picks the default browser, like a true shortcut to a URL would do. That said, you could make .LNK files point to URL's. In the end, they're "serialized COM monikers", and the COM system can be expanded with new moniker types.
    – MSalters
    Feb 2, 2016 at 23:12

A symlink is nothing more than a path wrapped up in a very small amount of filesystem magic. There are any number of ways it can become invalid ("broken"), most of which involve one or more files or directories getting renamed. Since Windows is consumer software, you may have a large number of very poorly designed programs running on a "typical" installation. As a result, this kind of breakage is a lot harder to avoid than on a server where (in theory) every program that touches the disk is a known quantity.

Shortcuts are immune to most forms of breakage since they track their targets independently of path. This makes them more user-friendly. They are specifically designed for consumers, with a "just do what I mean and don't bother me about the details" approach.

Now, you could use hard links for that (to some extent), but hard links have a number of complicated properties which make them unsuitable for consumer use. In particular, files get new inode numbers entirely too easily and some backup software breaks rather spectacularly when confronted with hard links. The former could (perhaps) be solved with filesystem tunneling (which is in fact how shortcuts solve a related problem), but the latter is a much harder problem.

(I should probably also note that "solving" hard links with tunneling is decidedly nontrivial since it's not just a matter of reattaching metadata that's "gotten lost." Inodes are bound up in the disk allocation scheme, so you can't just arbitrarily merge or reassign them after the fact without a fair bit of legwork. Since shortcuts use other metadata that can be easily tunneled, like the creation time, they don't have this issue.)


I realize this is an old question, but we continue to be plagued by Windows Explorer displaying Shortcuts and Symlinks in a manner that is almost indistinguishable and outright misleading.

  1. In Explorer views that show icons, both have a small up-right-pointing arrow in a box attached to the bottom left corner, so here they are represented indistinguishably.

  2. In the Explorer Tree view, Symlinks (for directories) appear as nodes, while Shortcuts do not appear.

  3. The right-click > Properties dialog is a muddle. For Symlinks there is no mention in this dialog of either "link" or "Symlink", and in fact the dialog displays a "Shortcut" tab with info on the Target Type, Target Location and actual Target path. There is a Start in field (greyed out, and doesn't apply to SymLink).

Meanwhile, for actual Shortcuts, the General tab shows "Type of file" Shortcut (.lnk). And the dialog omits the Sharing tab (for directories).

So if all that leaves you uncertain about what is what, you have to resort to a command window in which the dir command clearly identifies Symlinks with "" in the type column, while Shortcuts appear as ordinary files with their filename spelled out with the ".lnk" extension.

Of course, it's already a problem that shortcut's extension is an abbreviation of "link", when they are not links at all.

In short, Windows Explorer could do a much better job of clearly identifying and distinguishing these two rather different things, and certainly it should stop using terms for one or other that are misleading or outright wrong.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .