Image URL Regex
Matches an absolute HTTP or HTTPS URL that ends in a common image file extension, with an optional query string.
Regex Pattern
^https?:\/\/\S+\.(?:jpg|jpeg|png|gif|webp|svg|bmp|avif)(?:\?\S*)?$Default flags: i
Pattern Breakdown
Hover over a token to see what it does.
| Token | Meaning |
|---|---|
| ^ | Anchors the match to the start of the string |
| https? | Matches http or https |
| :\/\/ | Literal :// scheme separator |
| \S+ | One or more non-whitespace characters making up the host and path |
| \. | Literal dot before the file extension |
| (?:jpg|jpeg|png|gif|webp|svg|bmp|avif) | Non-capturing group of allowed image extensions |
| (?:\?\S*)? | Optional query string starting with ? |
| $ | Anchors the match to the end of the string |
Detailed Explanation
What it does
This pattern validates that a string is a full HTTP(S) URL whose path ends in one of the common raster or vector image extensions, optionally followed by a query string such as a cache-busting parameter or resize hint.
Why it works
The greedy \S+ consumes as much of the URL as possible, then backtracks just enough to let the literal dot and extension alternation match at the very end of the path, before any optional query string. Anchoring with ^ and $ combined with the case-insensitive flag ensures the whole string is a URL with no leading or trailing garbage, regardless of extension casing like .JPG or .Png.
Common use cases
- Filtering a list of URLs to only those pointing at images for a gallery component
- Validating an avatar or thumbnail URL field before saving it to a database
- Deciding whether to render a link as an <img> tag versus a plain hyperlink
- Pre-flight checks in a web scraper before attempting to download a file
Edge cases
- Uppercase extensions like .JPG or .PNG are matched because of the case-insensitive i flag
- Query strings such as ?w=300&h=200 after the extension are accepted without breaking the match
- A trailing slash after the extension, like image.jpg/, is intentionally rejected since the extension must be the final path segment
- URLs with no scheme, like example.com/photo.jpg, are rejected because http:// or https:// is required
- Extensions embedded mid-path, like /jpg/file.txt, are correctly rejected since the extension must trail the last dot before the end or query string
Limitations
- Relies purely on the file extension and does not verify the actual content type or MIME type of the resource
- Does not cover newer or less common formats like .heic, .tiff, or .ico unless added to the alternation
- Cannot detect images served without an extension, such as dynamically generated image endpoints
Interactive Tester
Edit the pattern or text below — matching runs live in your browser.
(%3F%3A%5C%3F%5CS*)%3F%24&f=ig&t=https%3A%2F%2Fexample.com%2Fimage.jpg%0Ahttp%3A%2F%2Fexample.com%2Fphoto.PNG%0Ahttps%3A%2F%2Fcdn.example.com%2Fimg%2Fpic.webp%3Fw%3D200){kind=link}
Test Cases
Editable — add your own inputs to see if they pass.
| Input | Expected | Result | |
|---|---|---|---|
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass | |||
| Pass |
Language Variants
Production-ready examples in 12 languages.
const imageUrlRegex = /^https?:\/\/\S+\.(?:jpg|jpeg|png|gif|webp|svg|bmp|avif)(?:\?\S*)?$/i;
console.log(imageUrlRegex.test('https://example.com/photo.webp')); // trueCommon Mistakes
Forgetting the case-insensitive flag, so uppercase extensions like .JPG fail validation
Fix: Add the i flag (or an equivalent case-insensitive compile option) since extensions are commonly written in either case
Allowing the extension to appear anywhere in the URL instead of only at the end, causing false positives like example.com/jpg-tutorial/index.html
Fix: Require the extension to be immediately followed by the end of the string or a query string using $ and an optional (?:\?\S*)?
Not accounting for a trailing slash added by some CDNs after the file extension
Fix: If trailing slashes are expected, add an optional /? before the end anchor
Performance Notes
- \S+ is greedy and will backtrack character by character to find the extension, which is fine for typical URL lengths but can be slow on extremely long, dot-free strings
- Anchoring with ^ and $ prevents unnecessary scanning across the whole input for a match
- The extension alternation is checked as a fixed set of short literals, which regex engines optimize well compared to a broader wildcard
Browser Compatibility
| Engine | Supported | Notes |
|---|---|---|
| Chrome | Yes | — |
| Firefox | Yes | — |
| Safari | Yes | — |
| Edge | Yes | — |
| Node.js | Yes | — |