Supabase storage: why your images stopped loading

Your app looks fine. The text is there, the buttons work, and where every picture used to be there's a grey box with a torn corner. Nothing you did this morning explains it.

What should I check first?

Right-click a broken image and open it in a new tab, on its own. That one move separates about five different problems, and they have different fixes. You will get one of three outcomes.

• The image loads fine on its own. The file is healthy and the problem is in your app — the address it is building, or the code around it.
• You get a small blob of text mentioning something not being found, or not being allowed. That text is the answer.
• You get nothing at all — a spinner, a page that never resolves. That is not a storage problem. That is your whole project being unreachable, and no amount of fiddling with folders will fix it.

Copy whatever text appears. Don't try to interpret it yet. You are going to paste it somewhere in a minute.

Does making a bucket public actually make it public?

Not in the way most people assume. Supabase keeps your files in things it calls buckets, which are just folders with a setting on them — and that setting is far more narrow than it sounds.

In plain terms: flipping a folder to public buys you exactly one thing — a link anyone can open in a browser. It does not make uploading work. It does not make listing files work. It does not make your app's "fetch this file" call work. Those all still go through the permission rules, and if your AI tool wrote those rules once and then rewrote them during a later change, the rules and the links stop agreeing.

This is why the symptom is so weirdly selective. Old images work and new ones don't. Or images work for you, logged in, and not for the person who emailed you. Or the picture shows in the editor preview and not on the real site. Same files, different doors.

If the folder is not public, the plain link cannot work at all. Supabase's docs put it flatly: assets in a non-public bucket are private and are not reachable through a public link. They can only be served by signing a time-limited link on the server, or by making a request with the user's authorisation attached.⁵ A private folder plus a public-style link is a guaranteed grey box, every time.

Why did it work yesterday and break today?

Because the links had a clock on them. If your app hands out temporary links to private files, those links stop working when their time is up.

If somebody — or something — saved those temporary links into your database as though they were permanent addresses, every one of them will work beautifully in testing and then expire, in batches, days later. That is the version of this problem that feels most like sabotage: you didn't touch it, and it broke anyway.

One useful detail if you've been regenerating keys in a panic: Supabase signs those temporary storage links with a dedicated internal key, separate from the one used for login tokens, and each project has its own.⁵ So resetting your login keys is not what killed your images — but links copied from a different project never had a chance of working.

What are the dumber causes worth ruling out?

The address being subtly wrong, and the files not existing. Both are more common than the interesting explanations, and both take a minute to check.

The link itself is wrong. In one Supabase discussion thread, a developer hitting a "resource not found" error found the fix was simply changing the bucket name to something other than "public" — the word collided with the word already sitting in the link path.³ Elsewhere in that same thread the official line is that nothing else is required once a bucket is public, and the link should just work; if it doesn't, open a support ticket.³ Both things are true, and together they tell you something: when a public folder's link fails, it is usually the link that's wrong, not the folder.

The files aren't there. Nobody checks this, because it feels impossible. But uploads fail quietly all the time, and your app happily saves a filename to the database regardless — so the picture has a name and a row and no actual file. Supabase's storage project has a logged case where a file in a folder marked public came back with an error whose outer label just meant "there was something wrong with this request", while the message tucked inside it said the folder itself could not be found.² The label on the error and the real problem were two different things.

You can see the same confusion from the builder's side. On the Figma forum in February, someone connected a Supabase photo folder to Figma Make and hit an error on every upload. Figma's community support replied that it looked unusual given the project clearly was connected, and suggested refreshing the preview, duplicating the file to work in a copy, and using the built-in "Fix for me" on the listed errors before escalating.⁶ Note what that implies: even the people who make the tool start by assuming the connection is lying about its own state.

So open your storage in the Supabase dashboard and look at the folder with your own eyes. If the files aren't in there, no permission setting on earth will make them appear.

Something you shipped last week changed the rules. If you asked your AI tool for anything touching login, permissions, or "make uploads secure," it may have rewritten the rules on your file folders as part of that. The images broke then. You noticed now.

How do I fix it, step by step?

1. 1
   Open one broken image on its own

   Put its link in a fresh tab and copy whatever text comes back, word for word.
2. 2
   Look in the dashboard

   Supabase → Storage. Is the file physically there? Is the folder marked public or not?
3. 3
   Hand all three facts to your AI tool

   The error text, the folder's setting, and one example of the full image link your app produces. Ask it to check that the link format matches the setting.
4. 4
   Stop storing links

   If your database holds temporary links, save the file's path instead and let the app build a fresh link each time it needs one.
5. 5
   If nothing responded at all, skip all of this

   Your project is unreachable, not misconfigured. That is a different problem entirely.

My app's images aren't loading from Supabase Storage.

The error I get when I open one image link directly: [paste the exact text]
The bucket is: [public / not public]
One example of the image link my app builds: [paste it]

Check whether the link format matches the bucket's setting. If the bucket is public, my app should build permanent public links. If it's private, it should sign a fresh time-limited link each time instead of reusing a stored one. Show me exactly which file and line to change, and don't change anything else.

How do I find out before my users do?

You need something looking at your app from outside, because broken images don't crash anything. The app is up. Nothing looks wrong on any dashboard. Someone just sees a wall of grey boxes and closes the tab, and you find out four days later, if at all.

There are several honest ways to do it, and they suit different people. Here is the short version.

Be clear about the trade. If you want a phone call at 3am from a server in Singapore, the established tools do that and Fomio does not. What it does instead is speak your language: when something breaks it says in plain English what likely went wrong, and on the Builder and Pro plans it writes the prompt to paste straight into the AI tool you built the app with — the exact step you were going to have to improvise anyway, halfway through a bad morning.

The free plan watches one app from outside, checks it every five minutes, emails you when it breaks, and keeps a week of history. It needs no card. Builder adds two more apps, checks every minute, the fix prompts, and a month of history; Pro goes to fifteen apps, a year of history, and status pages your users can look at themselves. Current prices are on fomio.ai/pricing.

Fix the images first. Then make sure the next thing that quietly breaks doesn't get four days' head start.