Show the folder path in Finder for documentation

When you're writing a README, a support article, or a step-by-step tutorial, "put the file in your Application Support folder" isn't good enough — a reader needs the exact path, spelled correctly. Turning on the full path in Finder's title bar means the canonical location is always on screen while you write, so you transcribe /Users/you/Library/Application Support/AppName instead of guessing at it. It's a one-line Terminal change and it undoes cleanly.

Put the canonical path on screen

Open Terminal and run:

# Show the full POSIX path in Finder title bars
defaults write com.apple.finder _FXShowPosixPathInTitle -bool true
killall Finder

Every Finder window now titles itself with its absolute path, written the exact way the file system stores it — forward slashes, real capitalisation, spaces intact. That's the form you want in documentation, because it's copy-paste-safe into Terminal and unambiguous to a reader on a different Mac. When the doc is finished, restore the plain folder name:

# Undo
defaults write com.apple.finder _FXShowPosixPathInTitle -bool false
killall Finder

There's no System Settings toggle for this — it's a hidden Finder preference — and it behaves the same on macOS 13 Ventura, 14 Sonoma, and 15 Sequoia.

Copy the exact path, don't retype it

Reading a path off the title bar catches mistakes, but for anything long you'll want to copy it verbatim so a stray typo never reaches your reader:

1. In Finder, right-click the folder (or file) you're documenting.
2. Hold Option. The Copy item changes to Copy "name" as Pathname.
3. Release on that item — the full POSIX path is now on your clipboard, ready to paste into your doc.

This is the safest way to get a path into prose or a code block, because it's the system's own string, not your transcription of it.

Format the path so it survives a copy-paste

How you present a path in a doc decides whether a reader can actually use it. A few rules keep them working:

• Wrap paths in inline code. Put single paths in a <code> span (or backticks in Markdown) so a proofreading tool doesn't autocorrect the capitalisation or turn straight quotes curly — either of which breaks the path.
• Quote paths with spaces. The title bar shows spaces as-is, but a reader pasting /Users/you/Application Support into Terminal needs it quoted — "/Users/you/Application Support" — or the space will split it into two arguments. Show the quoted form in any command a reader will run.
• Show the command, not just the location. If the point is "go here", pair the path with the action: cd ~/Downloads or open ~/Library/Logs is clearer than a path on its own, and it's copy-paste-ready.

Getting these right is exactly why having the real path on screen matters — you're transcribing a verified string and formatting it, not reconstructing it from memory.

Two conventions to keep your docs honest

• Tilde vs. full path. The title bar shows /Users/yourname/Documents, but in documentation a home-relative path is usually clearer for everyone: write ~/Documents, since ~ expands to each reader's own home folder. Use the tilde form for anything under the user's home, and the full /Library or /Applications path for system-wide locations.
• Hidden folders count. Many documented paths live inside ~/Library, which Finder hides by default. Hold Option and open the Go menu to reveal Library, then open it so its real path shows in the title bar — otherwise it's easy to write a path you can't actually navigate to.

With the full path visible and Copy as Pathname a right-click away, every location you reference is one you've verified on screen rather than remembered — which is the difference between a tutorial that works and one that generates support tickets.

Screenshots for the same doc

Docs usually pair a path with a picture. When you grab those, a lighter file format keeps the page fast — see how to save Mac screenshots as JPG to shrink them before they go into your tutorial.