Does a valid signed URL remove browser CORS requirements?

No. Cross-origin browser use still needs an appropriate CORS policy.

Is CORS a replacement for private-object authorization?

No. It controls browser access behavior, not who is authorized to receive a signed operation.

Why test both localhost and the production domain?

They are different origins and may require distinct allowed-origin entries.

Why can an R2 upload work on the server but fail in the browser?

Browsers enforce cross-origin rules that server-side clients do not enforce in the same way. A valid storage operation can therefore fail from a web page because its CORS configuration is incomplete.

Compare origin, method, and headers

Check the exact application origin, including scheme and port, along with the upload method and request headers. Configure the bucket’s allowed origins, methods, and headers for the intended browser flow. A signed URL still needs suitable CORS behavior when used cross-origin from browser JavaScript.

Test the browser path

Inspect the failing request and any preflight response. Separate an expired or invalid signature from an origin-policy mismatch; both may surface as an upload problem. Do not treat permissive CORS as authorization for private files. Repeat the test from the deployed origin because localhost and the production domain are different origins. Verify only the response headers the client actually needs to read.

Why can an R2 upload work on the server but fail in the browser?