Where do I store uploaded images or files for a small website?

This page may contain affiliate links from which Blur Studio earns commissions.

A common surprise for anyone newer to how modern websites actually work: the code that builds and serves your site isn't a place you can also write new files to while it's running. If a customer uploads a photo through a form on your site, that photo has to go somewhere else, a storage layer built for exactly that job, not into your website's own files.

What Netlify Blobs actually is

It's a built-in storage service you can use as a simple key-value store or basic file store, directly from your site's own functions, edge functions, build plugins or the Netlify CLI, with no separate account or service to configure. Netlify handles provisioning and access control automatically, which is the main appeal versus setting up something like Amazon S3 yourself: there's genuinely less to configure.

The real limits worth knowing before you build around it: individual objects can't exceed 5GB, store names are capped at 64 characters, object keys at 600 characters, and metadata per object at 2KB. For reference, 5GB per object comfortably covers individual photos, PDFs, or most single files a small business site would handle; it becomes a real constraint only if you're storing large video files or batches of files as single combined objects.

The consistency detail most people never think to ask about

Netlify Blobs offers two consistency modes, and the default one has a real, practical implication worth knowing upfront. Eventual consistency (the default) stores data in one region and caches it at the edge globally for faster reads, but updates or deletions can take up to 60 seconds to propagate everywhere. In practice, this means if someone uploads a file and then immediately tries to view it from a different location, there's a small chance they briefly see an older version or nothing at all for a few seconds. Strong consistency gives up some of that read speed in exchange for every reader seeing the update immediately, everywhere, and you can set this per store or per individual read/write operation depending on which specific pieces of data actually need that guarantee.

For most uploaded-image or simple-file use cases, the default eventual consistency is genuinely fine; a few seconds of lag before a brand new upload is visible everywhere rarely matters. Where it does matter is anything transactional, confirming a payment went through, updating a status a user is actively watching, where you'd want strong consistency specifically for that piece of data.

Site-wide versus deploy-specific stores

Blobs has two distinct store types worth understanding. Site-wide stores persist across every deploy and are shared across your whole site, the right choice for actual customer uploads you want to keep permanently. Deploy-specific stores are scoped to one particular deploy and are specifically meant for build plugins or temporary file uploads, preventing a failed or in-progress deploy from accidentally overwriting your live production data. If you're building something that handles real customer uploads, make sure you're using a site-wide store, not a deploy-specific one, or uploads can quietly disappear the next time you deploy a change.

When this isn't the right tool

Netlify's own guidance is direct that Blobs isn't built for complex lookups or relational data, pointing to a real database for that instead. If your actual need is "find all orders from this customer in the last 30 days" or anything involving filtering, sorting or relationships between records, a database (like Netlify's own built-in database option) is the right tool, with Blobs staying useful specifically for the files themselves (the actual photo, PDF or document) referenced from within those database records.

What I'd actually tell someone building this themselves

A lot of small sites genuinely only need the file-storage half of this problem: one uploaded photo per inquiry, one generated quote PDF per customer, nothing that needs searching or filtering later. For that, Blobs on its own is enough, and reaching for a full database adds complexity you don't need yet. The moment you find yourself wanting to list, search or filter what's been uploaded (which customer uploaded what, when, in what status), that's the signal you've outgrown file storage alone and need an actual database alongside it, with Blobs holding the files and the database holding the structured information about them.

A worked example: a home inspection business storing report photos

A home inspection business needed inspectors to upload photos directly from a job site through a simple form on their website, with each inspection generating anywhere from twenty to over a hundred photos tied to a specific property and date. Early on, the owner assumed this needed a full database build from day one, since "a hundred photos per job, organized and searchable" sounded like it obviously needed structured storage.

The actual build turned out simpler: Netlify Blobs held the photos themselves, in a site-wide store so they'd persist across every future site deploy, with each photo's key including the inspection ID and a sequence number so photos for one job stayed logically grouped without needing a database at all for the basic case. A lightweight database layer was added only for the part that genuinely needed it, looking up which inspection a given client's report belonged to and generating the final PDF report that bundled the right photos together. Splitting the problem this way, unstructured file storage for the raw photos, a minimal database only for the lookups that actually required one, kept the build considerably smaller than treating "store and organize everything" as one combined problem from the start.

A practical note on cleanup and storage growth over time

Upload-heavy sites tend to accumulate files faster than anyone expects once they're actually in use, and it's worth deciding early whether old uploads ever get deleted or archived, rather than assuming storage is unlimited and free to ignore indefinitely. For most small businesses this isn't an urgent problem, but a business generating hundreds of uploads a month is worth periodically checking against actual usage and billing, specifically so a forgotten batch of old, unneeded files doesn't quietly become a bigger cost than expected months or years down the line.

How I'd approach this

When I'm scoping a small business site that needs file uploads, I always ask what happens to that file after it's uploaded: does anyone need to search, list or filter uploads later, or is it genuinely just "store it and retrieve it by its own specific link when needed"? That answer decides whether Blobs alone is enough or whether it needs a database alongside it from day one. Getting this right early avoids a messier retrofit later, when you've already got a pile of unstructured files and someone asks for a simple report that now requires rebuilding the data layer around them.