How to Use the AWS S3 URL Parser

Paste an S3 URL — path-style, virtual-hosted-style, or an
s3://
URI — into the box.
Click Parse. The tool detects which of the three forms you pasted and extracts the bucket, key, and region instantly in your browser.
Read the breakdown, plus a warning if the bucket name contains dots (a real HTTPS gotcha explained below).
Nothing you paste is uploaded anywhere — this is pure string parsing running as JavaScript in your browser tab.

The Two URL Styles (Plus the CLI Shorthand)

S3 objects can be addressed with three different URL forms that all point at the exact same object:

Virtual-hosted-style (the recommended, default form): the bucket name is part of the hostname itself.

https://bucket-name.s3.region.amazonaws.com/key-name

Example:

https://my-bucket.s3.us-west-2.amazonaws.com/reports/2024/jan.csv

Path-style: the bucket name is the first segment of the URL path, after a bucket-agnostic S3 hostname.

https://s3.region.amazonaws.com/bucket-name/key-name

Example:

https://s3.us-west-2.amazonaws.com/my-bucket/reports/2024/jan.csv

The

s3://

URI shorthand: used by the AWS CLI and SDKs, not a real HTTPS URL at all.

s3://bucket-name/key-name

In every form, the key — the actual object path inside the bucket — is structurally identical. Only where the bucket name appears (hostname vs. path) and whether the region is encoded in the URL at all changes between the forms.

Legacy Regionless Endpoints

Both styles also have an older, regionless form that predates AWS's current per-region endpoint scheme:

https://s3.amazonaws.com/bucket/key

(legacy path-style) and

https://bucket.s3.amazonaws.com/key

(legacy virtual-hosted-style). Neither encodes a region in the URL — AWS resolves these to the

us-east-1

region. This tool recognizes both legacy forms and correctly reports

us-east-1

rather than an empty/unknown region.

The Dots-in-Bucket-Name Edge Case

S3 bucket names are technically allowed to contain dots (e.g.

my.data.bucket

), and this parser handles that correctly in both URL styles. But dotted bucket names have a real, commonly-hit consequence worth knowing: using virtual-hosted-style over HTTPS with a dotted bucket name breaks TLS certificate validation. AWS's wildcard SSL certificate for

*.s3.<region>.amazonaws.com

is only valid for a single hostname segment in place of the wildcard — a bucket name containing its own dot (like

my.data.bucket.s3.us-east-1.amazonaws.com

) introduces an extra segment the wildcard certificate cannot match, so an HTTPS client doing proper certificate validation will reject the connection. This tool flags any bucket name containing a dot for exactly this reason — AWS's own guidance is to avoid dots in bucket names unless the bucket is used only for static website hosting (which doesn't use virtual-hosted-style HTTPS the same way), or to use path-style addressing instead, where this problem doesn't arise.

What This Tool Does NOT Do

This is a structure-only parser. It does not call the S3 API, and it cannot confirm the bucket or object actually exists, is publicly accessible, or that you have permission to read it. A URL that parses cleanly here is grammatically well-formed — it is not proof the object is real or reachable.

Frequently Asked Questions

Which style should I use for new code? AWS recommends virtual-hosted-style for new applications — it's the current default, and AWS has been deprecating path-style access for buckets created after a certain date (with some documented exceptions).

Does the key ever need URL-decoding? Yes — a key containing spaces,

+

, or other special characters is percent-encoded in the URL. This tool decodes the key portion of the path before displaying it.

Is my URL uploaded or stored anywhere? No. The parsing runs entirely as JavaScript inside your browser tab — nothing is sent to a server, logged, or stored.

Is this tool free? Yes, completely free, no login, no limit.