What is the difference between a shortcut and a symbolic link?

A shortcut is a small file whose contents record where the target lives, and only the Windows shell knows to interpret it that way. A symbolic link is a filesystem object, so any program opening that path is transparently taken to the target. One is a file about a location; the other behaves as the location.

Why can't my program open a file through a shortcut?

Because a .lnk shortcut is only interpreted by the Windows shell, and to every other program it is just a file with unfamiliar contents. If an application expects a file at a given path, handing it a shortcut gives it the shortcut rather than the target, which is why double-clicking works while a script reading the same path does not.

When should I use mklink instead of a shortcut?

Whenever something other than a person needs to follow the link: a build process, a script, a game or application expecting its data in a fixed location, or a folder you want to physically live on another drive while still appearing where software expects it. Shortcuts are for human navigation, mklink is for making a path resolve differently.

How do you create a symbolic link on Windows?

With the mklink command in a terminal, using /D for a directory link, and it generally needs administrator rights or Developer Mode enabled. The syntax puts the new link first and the existing target second, which is the opposite order to what most people guess and the usual cause of a link that appears to point nowhere.

Is a macOS alias the same as a symlink?

No. An alias is a Finder construct that tracks the file itself, so it keeps working if the target is moved elsewhere on the same disk, whereas a symbolic link stores a path and breaks when the target moves. That resilience is why aliases are better for human use and worse for anything scripted, since Terminal tools do not follow them.

What does the -s in ln -s mean?

It makes the link symbolic rather than hard. A symbolic link is a pointer to a path, so it breaks if the target is deleted, while a hard link is another name for the same underlying data and keeps that data alive until every name is removed.

Shortcut vs Symlink: Why Your Program Can't Find the File

Here is the failure that brings most people to this question. You make a shortcut to a folder, put it where a program expects its files, and the program cannot find anything. Double-clicking the shortcut works perfectly. The program is adamant the folder is empty.

Nothing is broken. You made the wrong kind of link, and the difference is invisible in Explorer.

A Shortcut Is a File. A Symlink Is a Location.

A Windows shortcut is a small .lnk file. Its contents record where the target lives, as text, and the Windows shell knows to read that and jump there.^[1]

Every other program does not know that. To an application, a .lnk is a file with unfamiliar contents sitting where it expected your data.^[2] It does not resolve it, because nothing told it to.

A symbolic link, made with mklink, is a filesystem object. A program that opens the linked path is taken to the target by the filesystem itself, without knowing a link was involved.^[1]

“A shortcut is a file that says where something is. A symlink is treated as the place itself. Only the second one works when the reader is not a person.”

Which gives a rule you can apply without thinking about it:

A human is following the link — desktop launcher, Start menu entry, something in a folder you browse. Use a shortcut.^[1]
A program is following the link — a script, a build process, an application looking for its data, a game expecting a save directory. Use mklink.^[1]

Making a Symbolic Link on Windows

mklink, from a terminal. Add /D for a directory, and expect to need administrator rights or Developer Mode enabled.

The argument order is the part everyone gets wrong: the new link comes first, the existing target second. That is the reverse of how most people guess, and getting it backwards produces a link pointing at nothing, which reads as a broken command rather than a reversed one.

Why this matters

The most common legitimate use is moving something bulky off a full drive while software continues to find it where it always was. Symlink the original location to the new one and the application never notices, because the filesystem is doing the redirection rather than the shell. A shortcut cannot do this job at all, and that mismatch is what generates most of the confusion.

macOS: Aliases and Symlinks Are Also Different

Same split, different names, and one genuinely interesting distinction.

A macOS alias is a Finder construct, and it does something a symlink cannot: it keeps working when the target is movedelsewhere on the same disk, because it tracks the file rather than remembering a path.^[3]

A symbolic link, made in Terminal with ln -s, records a path.^[3] Move the target and the link points at nothing.

So the trade is the mirror of Windows. The alias is more robust for a human who reorganises their files, and useless for anything scripted, since command-line tools do not follow it. The symlink is more fragile to reorganisation and is the one every tool understands.

Symbolic vs Hard Links, Briefly

The -s in ln -s is what makes the link symbolic. Without it you get a hard link, which is a different idea worth knowing.

A symbolic link points at a path, so deleting the target leaves a dangling link. A hard link is another name for the same data: the data survives until every name is removed, and no name is more real than any other. There is no original to break.

Hard links cannot usually cross filesystems, since they reference the underlying data structure rather than a path, which is the constraint that decides the choice more often than anything conceptual does.

Diagnosing It

If a program cannot see files it should:

Check the file size. A .lnk shortcut is a couple of kilobytes regardless of what it points at. If the thing you thought was a folder is a 2 KB file, that is your answer.

Check the extension. Windows hides .lnk by default, which is a large part of why this confusion is so durable. Turn on file extensions and shortcuts stop being able to disguise themselves.

Try the path in a terminal. If cd into it works, it is a real filesystem link. If the shell treats it as a file, it is a shortcut, and no amount of retrying will change that.

Takeaway

A shortcut is a file containing a location and only the shell reads it, so every program that is not the shell sees a small unfamiliar file where it expected your data. A symbolic link is a filesystem object and resolves for everything. Use shortcuts for people and mklink or ln -s for programs, remember the link comes before the target in the arguments, and note that a macOS alias survives the target moving while a symlink does not.

For the wider picture of how paths, permissions and filesystem behaviour differ between the desktop platforms, the practical differences show up in settings that moved between Windows versions and in the Wayland versus X11 split, where the same command silently stops working for reasons nothing surfaces.

Sources and further reading

1.PrimaryMicrosoft Q&A, "Is there any significance in the difference between a symbolic link (MKLINK /D) and a shortcut?". Source for the shortcut being a shell-interpreted file that many applications treat as an ordinary file, mklink links being filesystem objects that programs resolve through the filesystem, and the resulting guidance on when to use each.
2.ReportingHow-To Geek, "Why does Windows still use shortcut files instead of symbolic links?". Source for shortcuts being interpreted only by the operating system while other programs see them as ordinary files.
3.ReportingThe Eclectic Light Company, "Aliases and links: understanding their differences". Source for a macOS alias continuing to work when the target moves on the same disk, unlike a path-based symbolic link created with ln -s.