Find the Trash folder on a Mac, in Finder and in the terminal

"Find trash on Mac" is two different questions wearing the same words. One of them is "where does the window open", and it has a one line answer. The other is "what is the path", and it does not have a single answer at all, because macOS keeps a separate trash folder on every mounted volume and shows them as one window.

Most pages answer the first question and stop. That is fine until the moment a script needs the path, or an external drive is still holding deleted files, or the Trash icon has gone from the Dock. At that point the difference between the window and the folder stops being academic.

The Finder answer: a Dock item rather than a sidebar entry

In the Finder, the Trash lives in the Dock. Clicking it opens a window with the deleted items and an Empty button in the upper right corner. Apple documents the same command in the menu bar as Finder > Empty Trash.

Two things in that window behave differently from an ordinary folder and are worth fixing in the mind before anything gets clicked.

Empty ignores the selection. It applies to the whole view. For one item, Apple documents Control-clicking it and choosing Delete Immediately instead.

Restoring is a menu command, not a drag. Selecting items and choosing File > Put Back returns each one to the folder it came from. Dragging them out puts them wherever the drag ends, and loses the record of where they belonged. When several items came from several folders, Put Back is the only route that reconstructs that.

What the Finder does not offer is a path. The window shows contents without showing location, which is exactly the information a script or a disk space investigation needs.

The terminal answer: a hidden folder in the home directory

Apple's Terminal documentation covers the shorthand that makes this readable. Paths are separated by slashes, and a tilde stands for the current user's home folder, so ~/Documents is the Documents folder in the home directory. The user trash folder follows the same pattern, with a name that begins with a dot.

The dot is the whole of the hiding mechanism. The manual page for ls documents its listing flag as including "directory entries whose names begin with a dot," and that is all that separates a hidden folder from a visible one on this system. There is no special attribute to clear and no permission to change.

Two practical notes follow.

Listing the folder sorted by modification time answers "what went in most recently", which the Finder window does not do by default. That is useful when something was deleted a minute ago and the window has a thousand rows in it.

Totalling the folder answers "how much space is this using". The disk usage utility documents a flag that displays a single entry for each specified file rather than one line per item inside it, which produces one number instead of a page of them. Both of these are reads. Nothing is moved, so nothing can go wrong.

Why there is no single Trash path

This is the part that the one line answers get wrong. The trash folder in the home directory covers the startup volume only. Every other mounted volume has its own.

The seam shows in Apple's own documentation from a different angle. Items moved to the Trash from the Mac stay there until the Trash is emptied, while items moved there from iCloud Drive are emptied after 30 days regardless of the Finder setting. One window, two rules, because the rows are coming from different places. The folder in the home directory is also readable only by its owner, which is why one account on a shared Mac never sees another account's deleted files.

Three consequences are the reason people end up searching for the folder in the first place.

Deleted files on an external drive take up space on that drive. Emptying the Trash while the drive is unplugged does not reclaim it, because the folder holding those files is not mounted. The disk stays as full as it was.

A drive can be handed over with deleted files still on it. They are removed only when that volume's trash is emptied with the volume connected.

The item count in the Trash window changes when a drive is ejected. Nothing was deleted. One of the sources of the combined view went away.

The design reason is short. Moving a file into a trash folder on the same volume is a rename, which is instant and needs no free space. Moving it to a trash folder on another volume would be a copy followed by a delete, which takes time proportional to the file size and can fail when the destination is short of space. A single shared Trash would be slowest and least reliable precisely when a disk is nearly full, which is when it gets used.

The question	The Finder answer	The path answer
Where is the Trash	The Trash icon in the Dock	A hidden dot folder in the home directory, for the startup volume
Where are deleted files from an external drive	The same Dock window, while the drive is mounted	A separate hidden folder on that volume
How big is the Trash	Sizes per item in list view, no total	One line from the disk usage utility
Restoring an item	Select it, then File > Put Back	Not available: the original location is Finder information
Deleting one item now	Control-click, Delete Immediately	rm, which has no bin at all

The last row is the one to read twice. Restoring belongs in the Finder and only in the Finder, because the record of where each file came from is not stored in the file.

Getting from the window to the path without typing it

Two documented shortcuts remove the main source of error here, which is transcribing a path by hand. External volume names are the worst offenders, because they usually contain spaces.

Apple's Terminal documentation is explicit about spaces: pathnames containing them need single or double quotation marks around them, or a backslash before each space, so that My\ Disk and "My Disk" mean the same thing. A drive called Backup Drive 2 is three words, and an unquoted path to it fails in a way that looks like the folder is missing.

The way around it is to stop typing paths. Apple documents that dragging a file or folder into a Terminal window puts "the item's absolute path" on the command line, with escaping handled. Dragging the mounted volume from the Finder into a shell gives its exact path, spaces and all.

The reverse direction is the open command, documented as opening a file, directory or URL "just as if you had double-clicked the file's icon." Given a trash folder path, it opens a normal Finder window on that one volume's deleted items rather than the combined Dock view, which is the only straightforward way to look at a single volume's trash on its own.

Both of those shortcuts exist because the folder and the window are in different applications, and the path is the thing that has to be carried between them. Keeping the folder and its terminal in one window is a way of not carrying it at all.

Deleting into the Trash from a shell instead of past it

Finding the Trash folder is often the second half of a question whose first half was how to delete something from the terminal without losing it. The rm manual page describes the command as attempting to remove the files named on the command line. No holding area appears in that description, and none is used.

macOS now ships an alternative. There is a trash command at /usr/bin/trash, documented in section 8 of the manual pages as moving "files and directories into the user trash folder," with a history line stating that it first appeared in macOS 15.0. It takes a verbose flag and a flag that stops on the first failure, and that is the whole interface. Files removed with it show up in the same Dock window as everything else, which means File > Put Back works on them.

Two related flags are worth the same habit. Both mv and cp document a flag that refuses to overwrite an existing file rather than replacing it silently. Overwriting is the failure mode that no Trash covers, because nothing was deleted: one file's contents simply became another's.

When the folder turns out to be empty

Finding the folder and finding it empty is a common ending, and it narrows the problem rather than closing it. Two mechanisms hold earlier states of files without using the Trash at all, and both are reachable.

Local snapshots are the fast one. Apple documents that Time Machine "also saves local snapshots you can use to recover previous versions of files, even if your backup disk is not attached," that they are created hourly, stored on the same disk as the originals, and "saved for up to 24 hours or until space is needed on the disk." The Time Machine utility documents a subcommand that lists local snapshots for a given mount point, and another that lists their creation dates, formatted as year, month, day and time. Listing them is a read and costs nothing, which makes it the right first move.

Read the expiry clause carefully, because it interacts badly with the situation people are usually in. Snapshots are discarded when the disk needs the space, and a disk short of space is exactly when files get deleted in a hurry. A snapshot that existed this morning may not exist this afternoon.

Document versions are the other route, for the case where a file still exists but its contents are wrong. Apple documents File > Revert To > Browse All Versions in apps that support it, which shows the current version against a timeline of earlier ones. Clicking Restore replaces the current version. Holding Option turns the button into Restore a Copy, which opens the older version in a new window and leaves the current file untouched.

What to change first

Use the Dock icon when the goal is to restore something, because File > Put Back is the only route that knows where each item belonged. Use the hidden folder path when the goal is to measure or list, because reading a folder cannot go wrong and selecting rows in a window can. And if an external drive is short of space, mount it and empty the Trash with it connected, since its deleted files live on the drive itself.

If the reason the path keeps getting typed by hand is that the folder and the shell are in different applications, that is the fixable part. Atriens gives each folder its own terminal in the same window, and the comparison page shows where that matters.