To understand symlinks, first we need to understand how applications access files and folders. Applications do not have direct access to the data of the files, or even to the filesystem itself. Instead, they must ask the operating system for the data using an identifier that we call a "filepath."
This means that the data an application gets is just what the operating system gives them. If the operating system tells a program that a file doesn't exist, it doesn't, and if it tells an application the file contains some data, then it does. The application has no way of knowing whether the operating system is lying or not. Whatever the operating system says is the truth;
A symlink is just a filepath that is a pointer to another filepath.
When an application asks the operating system for the data inside a filepath that points to a symlink, the operating system will look inside the symlink to check what filepath it points to, and will give the program the data for that filepath instead.
Imagine that you have a door in a house, and if you open it you get to the other side. Now imagine that there is a magical portal somewhere completely unrelated that also gets you to the other side of that door. That's how symlinks work.
Creating Symlinks
Because a symlink is just a pointer to a filepath, you can have a symlink that exists that points to a file that doesn't exist. For example, the terminal command ln -s is used to create symlinks in the terminal on Linux:
ln -s /file.txt /symlinkThis will create a symlink called /symlink that points to /file.txt. It works even if /file.txt doesn't exist.
Whenever a program checks if /symlink exists, the operating system will report whether /file.txt exists. In other words, it's all very transparent and handled entirely by the system. There are often separate methods to check if a filepath is a symlink if you want to check for that specifically, but the idea is that you shouldn't need to, and symlinks work just as if they were the actual files they point to from the perspective of the applications.
Saving Data to Symlinks
If we create a file at /file.txt later, /symlink will start giving its data. If we remove the file, /symlink will work as if the file didn't exist. If we try to edit /symlink, or save a file at /symlink, the operating system will automatically save the data at /file.txt. This even happens if the file doesn't exist. For example:
ln -s /file.txt /symlink
touch /symlinkAbove, let's assume /file.txt doesn't exist, but we create a symlink to it anyway. The touch command creates an empty file at the filepath we pass as first argument. We're creating an empty file at /symlink. What is going to happen is that /file.txt will be created when we do this.
Deleting a Symlink
On the other hand, deleting a symlink doesn't delete the file it points to.
rm /symlinkIf we do this, /symlink will be deleted, but /file.txt will still exist.
Symlinks to Folders
When a symlink points to a folder, a filepath may be partially compose of the symlink's filepath, and it will be resolved to the full filepath by the operating system. For example, let's say we do this:
ln -s /home/john/Pictures/Vacation /vacphotosIf an application tries to access /vacphotos/2025/beach.jpeg, for example, the operating system will give the application the data of the file /home/john/Pictures/Vacation/2025/beach.jpeg, if it exists.
Symlinks to Symlinks
Yes, we can symlink to another symlink. You can easily create an undebuggable maze of symlinks with this technique. The operating system will handle it transparently, resolving all symlinks without the application even needing to know about their existence. For example:
ln -s /foo /bar
ln -s /bar /baz
ln -s /baz /fish
ln -s /fish /fries
touch /friesThe code above will create /foo, assuming it didn't exist.
Why Symlinks Aren't Shortcuts
Symlinks may appear to be equivalent to shortcuts on Windows, but they're fundamentally not so. A shortcut is an useful utility for users to quickly open files and folders. Symlinks are more of a technical method to create aliases for filepaths.
Notably, if you create a shortcut to a folder on Windows, and double click on it, the file manager will open the folder at its actual filepath, e.g. C:\Users\John\Documents. In other words, the application is aware of what the shortcut is pointing to. This would go against the symlink philosophy that the application shouldn't need to know whether a filepath has any symlinks in it.
Consequently, if you have a symlink like /vacphotos and you open it in a file manager on Linux, what you see on the address bar will be /vacphotos/2025, for example, and not /home/john/Pictures/Vacation/2025.
Maybe I'm just not a smart man, but I find this behavior extremely confusing. Since it's completely transparent, there is no indication that I'm not working on a completely separate copy of the folder. There is just no way to tell the /vacphotos I'm browsing is just a reflection of /home/john/Pictures/Vacation, or I had copy and pasted the whole folder to there in the past. I'd really prefer it worked like it did on Windows.