Cloudflare R2 CORS Generator: Create Bucket CORS JSON for Browser Apps

What is a Cloudflare R2 CORS generator?

A Cloudflare R2 CORS generator helps you create the bucket policy that tells browsers which frontend origins can read or upload objects from R2. CORS is only enforced by the browser. Your presigned URL or public object may work in curl, but the same request can fail in a web app if R2 does not return the right Access-Control-* headers.

R2 CORS fields explained

Dashboard JSON vs Wrangler JSON

R2 developers often run into a small mismatch: the dashboard-style rule list and the Wrangler file shape are not always pasted in the same wrapper. The Spoold tool shows both forms. Use the editable CORS JSON for dashboard-style policy review, and use the generated Wrangler file when running wrangler r2 bucket cors set.

[
  {
    "AllowedOrigins": ["https://app.example.com"],
    "AllowedMethods": ["GET", "PUT", "HEAD"],
    "AllowedHeaders": ["Content-Type"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3600
  }
]

{
  "rules": [
    {
      "allowed": {
        "origins": ["https://app.example.com"],
        "methods": ["GET", "PUT", "HEAD"],
        "headers": ["Content-Type"]
      },
      "exposeHeaders": ["ETag"],
      "maxAgeSeconds": 3600
    }
  ]
}

Best presets for common R2 use cases

• Public assets: use GET and HEAD. Add Content-Length to exposed headers if the frontend reads file size.
• Presigned upload: use PUT, POST, and HEAD. Include Content-Type and any x-amz-* headers your upload sends.
• Signed download: use GET and HEAD. Expose ETag only if the frontend reads it.

What to enter before generating R2 CORS JSON

The best CORS policy starts with the real browser request, not a generic template. Before generating a Cloudflare R2 CORS config, collect the app origin, the object URL host, the upload or download method, and the request headers from DevTools. A production app at https://app.example.com and a local app at http://localhost:3000 are two different origins. If both need access, both must be present in AllowedOrigins.

For browser uploads, inspect your frontend code as well. A simple fetch(presignedUrl, { method: 'PUT', body: file }) may still send Content-Type. A richer upload component may add checksum, ACL, or metadata headers. Those headers become part of the preflight request and need to be allowed by the bucket policy.

Recommended R2 CORS policy shape

Keep the production policy narrow. Add only the origins that should use the bucket from a browser, only the methods your app actually calls, and only the headers that appear in Access-Control-Request-Headers. Wildcards can be useful while debugging, but a clean R2 policy is easier to audit when it names the real app domains.

How to generate R2 CORS config

1. Open the S3/R2 CORS tool and choose Cloudflare R2.
2. Pick a preset: public read, presigned upload, signed download, or fonts/assets.
3. Enter your production origin and any localhost origin used in development.
4. Add request headers from your frontend upload code.
5. Copy the editable JSON or download the Wrangler file.
6. Use the Debug tab if the browser still reports a preflight or missing-origin error.

Why use the debugger after generating config?

The generator gives you a good starting policy. The debugger checks the exact failing request. Paste your current R2 CORS JSON, the request origin, method, request headers, and browser console error. It will tell you whether the origin, method, headers, or exposed response headers are missing.

R2 CORS generator FAQ