It has the final pricing a client sent you three weeks ago. You remember saving it. You remember exactly what was in it. You just have no idea where it is.

You open your Desktop.

Screenshot 2026-10-04. Screenshot 2026-10-06. Screenshot 2026-10-08.

Hundreds of them. All looking almost identical.

You open Downloads. Nothing.

You try Spotlight and type “pricing.” It shows you a PDF from last year, three random documents, and pretty much everything except the screenshot you actually need.

So you start opening them one by one.

Click. Nope.

Click. Nope.

Click. Wait, was this the one?

Nope.

Forty minutes later, you finally find it. The screenshot was there the whole time. You just had to waste nearly an hour looking for something that took two seconds to save.

And the worst part? You know you’ll do this again next week.

Because if you’re anything like me, screenshots have become your second memory. A payment confirmation, a tweet you want to revisit, a snippet of code, a client’s requirements, a random idea at 2 AM. You screenshot everything because you know you’ll need it someday.

But someday comes, and you can’t find a damn thing.

Your Mac remembers the file. You remember the moment. And somewhere between the two, the information gets lost.

The problem isn’t that you take too many screenshots. It’s that your Mac organizes them by when you took them, while you search for them by what they meant.

And once you understand that, there’s a much better way to find them.

Let’s talk about why your usual search tools fall short, and how you can turn that pile of screenshots into something you can actually search.

Why your Mac can’t find the screenshot you’re thinking of

Every screenshot gets a name like “Screenshot 2026-10-07 at 4.12.33 PM”. That name tells you when you took it, and nothing about what it shows.

So when you search, you’re searching the one thing you don’t remember: the date.

What you do remember is a word on the screen (“pricing”, “invoice”, the client’s name), roughly who or what was in it, or that it was “the one with the blue chart”. To find a screenshot, a search tool has to read the image itself.

Here’s how the built-in options handle that.

1. Spotlight: fast, but it’s a file search

Spotlight is great at finding apps, documents and anything with a useful name. Recent versions of macOS can also pick up some text inside images, so it’s worth trying first.

The catch: results are mixed in with every document, email and setting on your Mac, there’s no preview grid to scan, and it’s hit or miss on older screenshots. When you have hundreds of near-identical file names, a list of names doesn’t help much.

Good for: finding a file when you remember its name.

2. The Photos app: good search, wrong folder

The Photos app has real search. It recognises objects, text and faces.

The catch is right there in the name: it only searches what’s in your Photos library. Screenshots on a Mac land on the Desktop (or wherever you pointed them), not in Photos. Unless you import them by hand every week, Photos never sees them. Same for images in Downloads, chat exports and screen recordings.

Good for: photos from your iPhone that already sync to iCloud Photos.

3. Finder: sorting, not searching

Finder can sort by date, show a gallery view and filter by kind. If you know it was “early October”, you can narrow it down.

But you’re still scrolling and opening files one by one. That’s exactly the forty minutes you lost at 11:40 PM.

Good for: cleaning up, not finding.

The one idea: search what’s inside the image

All three tools search around the image: its name, its folder, its date. The fix is a search that reads the image itself, the way you remember it:

• The text on screen (every word, from every screenshot)
• The people in your photos
• Where it came from: Desktop, Downloads, iPhone, screen recordings

And because these are your screenshots (bank pages, chats, passwords you shouldn’t have screenshotted), it should do all of that on your Mac, without uploading anything.

That’s exactly what Photsy does.

Photsy: a search engine for every screenshot, photo and video on your Mac

Photsy’s library: every screenshot, photo and video on the Mac in one searchable place.

Photsy indexes the screenshots, photos and videos across your Mac and lets you search them by what’s in them. Type “pricing” and you get every screenshot with the word “pricing” on screen, as a grid you can scan in a second. Your forty minutes become ten seconds.

What it does:

• Reads the text inside every image, so you search by what was on screen, not by file name
• Groups faces into people, so “every photo with Riya” is one click
• Covers the folders Photos ignores: Desktop, Downloads and the rest, not just your Photos library
• Imports straight from an iPhone
• Everything runs on your Mac. Your screenshots never leave it

It also fixes the small annoyances that usually send you to a converter website:

• HEIC to JPG and MOV to MP4 in one click (iPhone photos and screen recordings that won’t upload anywhere)
• Make a PDF from a set of screenshots (receipts, notes, a bug report)
• Build a collage without opening a design app

Price: one-time, $9 for 1 Mac or $19 for 3 Macs for the first 50 buyers. No subscription.

Try it here: Photsy

How to set it up so this never happens again

1. Install Photsy and let it index your Desktop, Downloads and screenshot folder. The first index takes a while if you have years of screenshots; after that it keeps up on its own.
2. Search by what you remember, not the date: a word on screen, a person, a site name.
3. Keep taking screenshots. That’s the point. Screenshots are the fastest way to save something, as long as you can get them back.
4. Clear out the junk once a month: search for things you know are useless (“captcha”, “loading”) and delete them in bulk.

Which one should you pick?

If you remember the file name, Spotlight is already on your Mac and it’s instant.

If everything you care about is iPhone photos synced to iCloud, the Photos app’s search is good enough.

If you take screenshots to remember things (chats, prices, receipts, error messages, ideas) and they live on your Desktop and in Downloads, you need search that reads the image. That’s Photsy.

So next time it’s 11:40 PM, you type “pricing” and the screenshot is the first result. You’re asleep by 11:45.

Quick answers

How do I find an old screenshot on Mac? Search by what was on screen, not by name. Spotlight sometimes finds text inside images, but for screenshots on your Desktop and in Downloads, an app like Photsy that reads the text in every image finds it in seconds.

Can I search the text inside images on a Mac? Yes. Photsy reads the text in every screenshot and photo on your Mac and makes it searchable, all on-device.

Where do screenshots go on a Mac? By default, to the Desktop, named “Screenshot at ”. You can change the folder from the Screenshot app (press Shift-Command-5, then Options).

How do I convert HEIC to JPG on a Mac? Preview can export one file at a time (File → Export → JPEG). Photsy converts HEIC to JPG, and MOV to MP4, in one click, for one file or many.

My SSD is 228 GB.

If you searched "Docker.raw 1TB" because your Mac showed you the same thing, you probably had the same moment. A file four times bigger than the disk it lives on, and your first instinct is to delete it.

Don't. Here's the output that changed my mind:

$ cd ~/Library/Containers/com.docker.docker/Data/vms/0/data
$ ls -klsh Docker.raw
1844848 -rw-r--r--@ 1 priyanshutiwari  staff   1.0T Oct 30 07:48 Docker.raw

Two sizes on one line. The 1.0T near the end is what the file claims. The 1844848 at the start is what it actually uses, in kilobytes. That's about 1.8 GB.

So the scariest file on my Mac was innocent. This is what I learned chasing it, and where my space really went.

The one idea: a file has two sizes

Most of us think of a file's size as one number. It's really two:

• Logical size: how long the file says it is.
• Physical size: how much of the disk it actually occupies.

For nearly every file you own, those match, give or take. A sparse file is one where they don't. The file says "I'm 1 TB long", but the filesystem only stores the parts that have been written. The empty stretches aren't stored anywhere. They just read back as zeros.

Think of a 1,000-page notebook where only the 2 pages you wrote on physically exist. The page numbers still go up to 1,000.

macOS will show you both numbers for my Docker.raw if you ask it directly:

$ mdls -name kMDItemFSSize -name kMDItemPhysicalSize Docker.raw
kMDItemFSSize       = 1099511627776
kMDItemPhysicalSize = 1889124352

That's 1,099,511,627,776 bytes claimed and 1,889,124,352 bytes used. Under 0.2% of what it says it is.

Make your own fake 10 GB file

I didn't fully believe this until I made one. It takes 10 seconds and costs you no space. Run it in a temp folder:

cd "$(mktemp -d)"
dd if=/dev/zero of=sparse.img bs=1 count=0 seek=10g
ls -lh sparse.img   # says 10G
du -h sparse.img    # says 0B

On my Mac, ls said 10G and du said 0B. A 10 GB file on a disk with 5.9 GB free, using nothing.

Then I wrote 2 bytes into the middle of it, 5 GB in:

printf hi | dd of=sparse.img bs=1 seek=5368709120 conv=notrunc
du -h sparse.img    # says 16K

16K. The filesystem stored one small block for those 2 bytes and still didn't bother with the other 10 GB. A plain cp on the same disk kept the copy sparse too, at 0B.

That's the whole trick. ls reports the claim. du reports the disk. When they disagree, believe du.

One limit on what I tested: all of this was on APFS, on one Mac. I didn't try zipping the file, uploading it or copying it to another drive, so don't assume it stays small on those trips.

Why Docker does this on a Mac

Containers need Linux, and a Mac isn't Linux. So Docker Desktop runs a Linux VM and, as its Mac FAQ puts it, keeps your containers and images in one large disk image file instead of a folder like /var/lib/docker.

The VM wants to see a big disk. Your Mac doesn't want to give up that space on day one. Sparse storage solves both: the VM sees the full size, and the Mac only pays for what's been written.

The same FAQ warns about the exact thing that scared me. Many tools report the maximum size of that file, not the size it's really using.

So the 1 TB is a ceiling, not a bill. That also means it isn't a reservation. With a 1 TB ceiling on a 228 GB disk, nothing in that number stops Docker from filling my drive first. The ceiling tells you nothing about your free space. Only du does.

When Docker really is the problem

Sometimes the physical size is the big one. A real image-heavy setup can use tens of GB. Check the physical number first, then use these, in this order.

1. See what's inside. With Docker running:

docker system df

This breaks usage down into images, containers, volumes and build cache.

2. Prune what's unused.

docker system prune

Docker's FAQ says this removes stopped containers, unused networks, dangling images and build cache, and that it can take a few minutes for the space to come back on the Mac. So don't panic if du doesn't drop right away. Read the confirmation prompt before you say yes, especially if a stopped container holds something you care about.

3. Know what doesn't help. The FAQ says deleting files inside a running container doesn't free the space automatically. It lists a command to trigger that:

docker run --privileged --pid=host docker/desktop-reclaim-space

4. Treat the disk limit as a last resort. The setting lives under Settings > Resources > Advanced, called Disk usage limit on the current settings page. The FAQ, which calls it the disk image size, warns that reducing it deletes the current disk image, and all your containers and images go with it.

And two things not to do. Don't drag Docker.raw somewhere else in Finder, because the FAQ says Docker Desktop can lose track of it. Use the Browse option in settings. And don't delete it to "fix" a 1 TB reading, because you'd be wiping your local containers and images to recover whatever du says it was using. For me, that's 1.8 GB.

A note on what I ran: the ls, mdls, dd and du output above is from my Mac. I didn't run the prune commands for this piece, because with 1.8 GB in there I had nothing worth pruning. Those steps come from Docker's docs.

Where my space actually was

Once Docker was cleared, I had to find the real culprits. Measure the folders, not the file list:

du -xh -d 1 ~ 2>/dev/null | sort -h | tail -15

Because du counts physical size, a sparse file can't fool it. On my Mac the real weight was in two places: codes at 59 GB and Group Containers at 28 GB.

I'd spent my time staring at a 1 TB file using 1.8 GB. The actual problem was 87 GB sitting in two folders I never look at.

I got from 7.3 GB free to 17 GB, stopping before anything I couldn't get back. WhatsApp media, for one, is something to look through yourself, not bulk-delete.

And two days later, I was back down to 5.9 GB free. So the honest lesson isn't "I fixed it". It's that the number you stare at should be the right number.

Quick answers

Why is Docker.raw so big on my Mac? It usually isn't. It's a sparse file, so tools like ls show the maximum size while the disk stores far less. Run ls -klsh Docker.raw or du -h Docker.raw to see the real number.

Why does Docker.raw say 1 TB? 1 TB is the ceiling Docker set for its Linux VM's disk, not what it's using. The VM sees the full size, and your Mac only stores what has been written.

Is Docker why my Mac's System Data is so big? It can be part of it. Before deleting anything, check the physical size of Docker.raw with du, then measure your home folder the same way. Mine turned out to be 1.8 GB, and the real weight was elsewhere.

Where is Docker.raw on a Mac? Docker's FAQ uses ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw as its example, and mine is there too. Settings > Resources > Advanced shows the exact location for your install.

Can I delete Docker.raw? You'll lose your local containers and images, so only do it if you're fine rebuilding them. Try docker system df and docker system prune first.

Why doesn't my disk space come back straight after pruning? Docker's FAQ says it can take a few minutes for the Mac to get the space back.

What's the difference between ls and du?ls -l shows how long a file claims to be. du shows how much disk it occupies. They only disagree in a big way on sparse files, and that's when du is the one to trust.

I write about what I run into while building things, usually at 4 am and usually on a full disk. If that's your kind of problem, follow me on X.

I never went to college. Everything I know, I learned by building things and breaking them — 84 public repos: Solana programs, a Polymarket bot, a memecoin betting app, and now AI products and Mac apps. That path teaches you one thing very well: how to make something exist.

It teaches you nothing about getting someone to pay for it.

When something breaks, you get an error

You read it, you fix it, and it works. Effort goes in and a result comes out, usually the same night.

Selling has no error message.

My product got visitors, and they looked around and left. No stack trace told me why. For someone who learned everything by debugging, that is a strange feeling.

Why the traffic fooled me

When I launched Actuity on X, the post did 8,100 views, 107 likes and 58 replies. For my account, that was huge. I felt like the hard part was over.

Views feel like progress because they arrive fast and they have a number on them. So does a commit graph. Both tell you that you were busy. Neither tells you that someone needed the thing enough to take out a card.

Then I looked at one week of my own numbers:

• A five-word post with a photo, "new toy in the house", got the most likes of the week: 108.
• My post asking for help with distribution got 4,600+ views, far more than most posts about what I actually built.
• My posts that tagged a real person had a median of 2,362 views. The rest had 433.

People were happy to watch me. Watching costs nothing.

Three things I confused

An audience is not a market. The people who follow me are mostly builders. They like seeing someone ship. Most of them are not looking for what I am selling that day. A like from another developer feels great, and it pays nothing.

Reach is not intent. Someone scrolling X at midnight is not shopping. Someone who types their exact problem into Google is much closer to paying. I spent my energy on the first group because the feedback is instant.

A launch is not distribution. A launch is one day. Distribution is whatever still brings people in on an ordinary Tuesday, three weeks later, when you have stopped talking about it.

I would have told you all three of these sounded obvious. I still got them wrong.

What I am doing about it

No guru steps here, because I do not have the result yet. These are the questions I am working through now:

• Who paid, and where did they come from? Before I chase more traffic, I want to know what the few buyers have in common.
• Where do people who already have this problem go looking? That is search, communities and comparison pages, not my timeline.
• What would I say to one person? A post has to work for everyone. A conversation only has to work for one person, and you hear the objection directly.

My next launch is Actuity v1.1. This time I want to judge it by what happens the week after, not by the view count on launch day.

The part nobody puts on a roadmap

I am 22 and I have said publicly that I think I found my way to $100k in six months. A 0.01% conversion rate is a useful thing to look at when you have said something like that out loud.

The good news is that this is a skill too. I learned Solana with no syllabus, and I learned Mac apps with no syllabus. I can learn why people buy the same way: try something, read what comes back, fix it, try again.

The only difference is that this time the error messages are silence, so I have to go and ask.

If you have got past this stage, I would really like to hear what changed for you.