React Application File Storage

React runs in the browser, and the browser is the one place you must never put a storage credential — which shapes the entire correct pattern for file storage in a React app. The flow is: your component captures a File from an <input type='file'> or a drop zone, sends it to your own backend (an Express/Nest server, a Next.js Route Handler, or a serverless function), and that trusted server calls files.link with your API key.

The browser never sees the key. On the server, the upload is three calls — POST /v1/files/{folderId} to get a presigned URL and id, PUT the bytes, then POST /v1/files/confirm-upload with { ids: [...] } — authenticated with the raw API key header. The server returns the resulting CDN URL to React, you store it against your record, and rendering is then dead simple: <img src={url} /> or any component, pointed at a permanent URL served from a global edge network.

A clean UX is to optimistically show a local object URL (URL.createObjectURL(file)) while the upload is in flight, then swap to the CDN URL when your backend responds. If you want true direct-to-storage uploads (large files that shouldn't proxy through your server), have the backend perform only step one — return the presigned PUT URL to the browser — let React PUT the bytes straight to that URL, and have the backend perform the confirm step after; the long-lived API key still never leaves the server, only the single-use presigned URL does.

This vendor-neutral REST approach is the main contrast with Firebase Storage and Supabase Storage, which want their client SDK and security-rules model embedded in your bundle, and with Uploadthing, which wraps the flow in its own typed library and hosting. files.link adds no SDK and no bundle weight; it's whatever fetch you already write. Private files — user avatars that should be account-scoped, paid downloads — stay private and are served via expiring signed URLs your backend mints after an auth check, so nothing sensitive rides on a guessable public URL.

Billing is prepaid credits rather than per-seat or per-request tiers, which fits an app whose upload volume you can't predict yet. The same backend pattern powers the Next.js and Node.js guides linked below if your stack spans both.