AWS S3 CORS Configuration Generator
Generate AWS S3 CORS configurations in JSON and XML for web apps, SPAs, and cross-origin uploads — entirely in your browser.
Build JSON-compliant S3 Cross-Origin Resource Sharing (CORS) rules for presigned uploads, SPAs, and web fonts.
CORS Rules (1)
Generated S3 CORS JSON
aws s3api put-bucket-cors --bucket my-app-uploads --cors-configuration '{"CORSRules":[{"AllowedMethods":["PUT","POST","GET"],"AllowedOrigins":["https://app.example.com","https://example.com"],"AllowedHeaders":["*"],"ExposeHeaders":["ETag","x-amz-meta-custom-header","x-amz-server-side-encryption"],"MaxAgeSeconds":3600}]}'Do it offline:$ aws s3api put-bucket-cors --bucket my-bucket --cors-configuration file://cors.json
How to use it
- Enter your target Amazon S3 bucket name (e.g. my-app-uploads).
- Select an architecture preset (Presigned browser uploads, Public web fonts, or Localhost dev environments) or build custom rules.
- Select allowed HTTP methods (GET, PUT, POST, DELETE, HEAD) and specify trusted origins.
- Define allowed request headers (like Authorization and Content-Type) and expose headers (like ETag) required by client JavaScript.
- Set the browser preflight cache duration (MaxAgeSeconds) to reduce OPTIONS request overhead.
- Copy the valid CORSRules JSON document or the ready-to-run aws s3api put-bucket-cors CLI command.
Generate valid JSON Cross-Origin Resource Sharing (CORS) configurations for Amazon S3 buckets. Enable browser presigned URL uploads, single-page application API access, and web font sharing with security linting against wildcard write access.
How it works
Browsers enforce the Same-Origin Policy (SOP). Cross-origin HTTP requests made via fetch() or XMLHttpRequest require the server to reply with Cross-Origin Resource Sharing (CORS) headers.
When a web application uploads directly to S3 via presigned URLs, the browser dispatches an HTTP OPTIONS preflight request. S3 evaluates the bucket's CORSRules and replies with Access-Control-Allow-Origin.
The ETag header contains the MD5 digest of the uploaded S3 object. Exposing ETag in ExposeHeaders allows the frontend upload library to confirm upload integrity.
MaxAgeSeconds controls how long the client browser caches preflight OPTIONS responses, reducing network round-trips for high-volume upload workflows.
Examples
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
Common errors
FAQ
Why does my frontend fail to read the ETag header after S3 upload?
By default, browsers only expose simple response headers (Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma) to JavaScript. To access S3-specific headers like ETag or x-amz-request-id in your frontend code, you must explicitly list them in the 'ExposeHeaders' array of your S3 CORS configuration.
Is it safe to use AllowedOrigins: ['*'] with PUT or POST?
No! Allowing wildcard origins ('*') with write methods allows any malicious third-party website to initiate uploads or modifications to your S3 bucket using your users' credentials. Keep wildcard origins restricted to GET and HEAD requests for static assets, and restrict write methods to your exact application domain names.
What is the difference between S3 Bucket Policy and S3 CORS?
An S3 Bucket Policy determines who (IAM principals, AWS accounts, or anonymous users) is authorized to perform S3 actions on the bucket. S3 CORS determines which web domain origins can access S3 resources through client-side web browser JavaScript. You often need both: a CORS rule allowing your frontend domain, and a bucket policy granting read/write permissions.