URL Extractor
Quick Access to Regex Tools
Go straight to the regex utility you need.
How to Use the URL Extractor
Paste the text containing URLs
Paste the text containing URLs.
Click Extract
Click Extract.
Copy the list of found URLs
Copy the list of found URLs.
URL Extractor � Extract URLs from Text
URLs show up everywhere � buried in email threads, embedded in markdown documents, scattered through JSON logs, hiding in server access files, and mixed into word-of-mouth Slack messages. Finding them by hand is slow and unreliable, especially when they span multiple lines or contain encoded characters. The URL Extractor scans your text with a regex pattern tuned for HTTP and HTTPS URLs, then returns a clean, deduplicated, alphabetically sorted list.
The entire process runs in your browser. Nothing gets uploaded, no data leaves your machine. Paste your text, hit extract, and get a usable list of URLs in seconds.
How URL Regex Matching Works
URLs follow a predictable structure: a scheme (http:// or https://), followed by a domain name or IP address, optionally followed by a port number, a path, query parameters, and a fragment identifier. The extraction pattern matches this structure by looking for the scheme prefix, then greedily consuming valid URL characters until it hits a boundary like whitespace, a closing parenthesis, or the end of the text.
The tricky part is determining where a URL ends. There's no universal delimiter � a URL in the middle of a sentence might be followed by a space, but a URL at the end of a parenthetical statement might be followed by ). The pattern handles the most common boundary conditions while being permissive enough to capture URLs with complex paths, query strings, and fragments.
URL Validation Patterns: What Makes a URL Valid?
A "valid" URL is surprisingly hard to define. RFC 3986 provides the formal grammar, and it's extraordinarily permissive � almost any combination of characters can technically form a URI if you squint hard enough. In practice, validation means checking that a URL has the expected structure: a scheme, a host, and optionally a path, query, and fragment.
The basic validation pattern for HTTP/HTTPS URLs breaks down into these parts. The scheme matches https?:// � the s is optional, making both HTTP and HTTPS valid. The host matches domain names (www.example.com), IP addresses (192.168.1.1, [::1] for IPv6), or localhost. The port is optional, preceded by a colon: :\d{1,5}. The path consists of segments separated by slashes, optionally ending with a file extension. The query string starts with ? and contains key-value pairs. The fragment starts with # and points to an in-page anchor.
A common validation mistake is allowing too many characters in the host portion. Domains can only contain letters, digits, hyphens, and dots � not underscores, spaces, or special characters. A "URL" like https://my_invalid_domain.com is technically invalid because of the underscore, even though most browsers will try to resolve it anyway. For strict validation, restrict the host pattern to [a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?(\.[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?)*.
Supported URL Formats
Standard HTTP/HTTPS: https://www.example.com, http://blog.test.org/articles � the bread and butter of web URLs. With paths and parameters: https://example.com/products?category=books&page=2, https://site.com/search?q=hello+world&lang=en. With ports: https://localhost:3000/api/users, http://intranet:8080/dashboard. With fragments: https://docs.example.com/guide#installation.
The tool intentionally focuses on HTTP and HTTPS schemes. FTP, mailto, telnet, and other URI schemes are excluded because they produce frequent false positives in general text. An email address like mailto:[email protected] looks like a URL to a greedy pattern, but it's almost never what you actually want to extract.
Query Parameter Extraction and Analysis
Query parameters are the key-value pairs after the ? in a URL. They control search results, pagination, filtering, tracking, and more. Extracting and analyzing them reveals a lot about how a website works � and sometimes exposes information you didn't expect to be public.
Common parameter patterns: Pagination uses ?page=2 or ?offset=20. Search uses ?q=query or ?s=query. Sorting uses ?sort=date or ?order=desc. Filtering uses ?category=tech or ?status=active. Session tracking uses ?utm_source=google, ?ref=homepage, or ?session_id=abc123.
Security implications: Query parameters sometimes contain sensitive information that shouldn't be in URLs. Session tokens, API keys, email addresses, and internal IDs all appear in query strings with alarming frequency. When extracting URLs for security audits, pay special attention to parameters that look like tokens (?token=, ?key=, ?api_key=) or personal data (?email=, ?user_id=). These URLs should never be shared, cached, or logged in plain text.
Extracting parameter keys: If you want to analyze which parameters are used across a site, extract the URLs first, then use a second pass to pull out just the parameter names. The pattern \?([^&=]+)= captures each parameter key from a query string. Deduplicate these to get a list of every parameter the site uses � useful for API discovery, security testing, and competitive analysis.
Fragment Identifiers: The Overlooked URL Component
The fragment identifier (everything after the #) points to a specific section within a web page. It's never sent to the server � the browser handles it client-side. Despite being invisible to server logs, fragments are useful for several extraction tasks.
Single-page application (SPA) routing: Many modern SPAs use fragments for navigation: https://app.example.com/#/dashboard/settings. Extracting these URLs gives you a map of the application's routes. Since the server sees only the base URL, fragment-based routing is a common pattern in JavaScript-heavy applications.
Documentation anchoring: Technical documentation uses fragments extensively: https://docs.example.com/api#authentication, https://wiki.example.com/Regex#quantifiers. Extracting these tells you which specific sections are being linked to � valuable for understanding which topics get the most cross-references.
Handling truncated URLs: Fragments can cause extraction issues when they're followed by punctuation. A URL like https://example.com/page#section. includes the period after the fragment in some interpretations but not others. The extractor handles this conservatively, treating the fragment as ending at the first whitespace or obvious boundary character.
International Domain Names and URL Encoding
Internationalized Domain Names (IDN) allow domain names to contain non-ASCII characters � like ??.jp or m�nchen.de. In practice, browsers and DNS servers convert these to a punycode representation (xn--r8jz45g.jp, mnchen-3ya.de) for resolution. The extractor handles punycode-encoded domains normally because they're pure ASCII. Raw Unicode domains may or may not be captured depending on the encoding in the source text.
URL encoding (percent-encoding) replaces special characters with %XX sequences. Spaces become %20 or +, non-ASCII characters become multi-byte sequences like %E2%9C%93 (checkmark), and reserved characters like /, ?, and # are encoded when they appear in the "wrong" part of the URL. The extractor preserves URL encoding as-is � it doesn't decode the characters because encoding is part of the URL's canonical form.
When you're extracting URLs from different sources, be aware that the same URL can appear in multiple encoded forms. https://example.com/path%20name and https://example.com/path name and https://example.com/path+name all resolve to the same page (in most contexts), but they're different strings. The deduplication step catches exact duplicates but won't normalize different encodings of the same URL. If you need canonical URLs, run the extracted list through a URL normalization function that decodes unreserved characters, sorts query parameters, and lowercases the host.
Practical Use Cases
SEO audits: Crawl a sitemap or a large HTML document, paste the source into the extractor, and you've got a quick list of every internal and external link. Cross-reference this with your analytics data to find pages that are linked but not receiving traffic, or pages that receive traffic but aren't properly linked.
Link analysis and broken link checking: Paste a blog post, documentation page, or knowledge base article to pull out all referenced URLs. Feed them into a link checker to identify dead links before your users do. This is especially useful for content that was assembled from multiple sources and may contain stale references.
Content migration: When moving a website to a new platform or restructuring URLs, extract all links from the old site's HTML. This gives you a comprehensive map for setting up redirects, ensuring nothing falls through the cracks during migration.
Security and compliance reviews: Extract URLs from emails, documents, or Slack exports to audit what external resources are being referenced. Identify unauthorized third-party services, exposed internal endpoints, or suspicious links that warrant investigation.
Research and documentation: When compiling references from multiple source documents, paste each one and extract the URLs. You'll end up with a deduplicated list of every source, ready to organize into a bibliography or reference sheet.
Bulk Extraction Strategies
When you're working with large datasets � entire website crawls, months of server logs, or concatenated email archives � efficient extraction requires some planning. Pre-filter your input. If you're working with HTML, strip out <script> and <style> blocks before extraction. These contain JavaScript and CSS, not real content URLs, and they generate noise in your results. A simple pre-processing step that removes these blocks dramatically improves the quality of extracted URLs.
Batch processing. For very large inputs (multi-megabyte files), break the content into 1-2MB chunks and process each separately. The deduplication ensures no duplicates appear in the final combined list. This also prevents browser slowdowns that can occur with extremely large text areas.
Post-extraction filtering. After extraction, filter the results by domain, scheme, or path pattern. If you only care about URLs from a specific domain, filter the list to exclude everything else. If you want to analyze only URLs with query parameters, filter for URLs containing ?. This post-processing step is often more efficient than trying to write a regex that extracts only the URLs you want in a single pass.
Deduplication with normalization. For the highest quality results, normalize URLs after extraction: lowercase the scheme and host, sort query parameters alphabetically, remove default ports (:80 for HTTP, :443 for HTTPS), and remove trailing slashes from paths. Then deduplicate the normalized list. This catches URLs that are functionally identical but textually different.
Understanding URL Structure
A URL has five main components. The scheme (https) specifies the protocol. The authority (www.example.com) identifies the server. The path (/products/shoes) specifies the resource on that server. The query string (?color=red&size=10) passes parameters to the server. The fragment (#reviews) points to a section within the page.
Understanding this structure helps you write more targeted extraction patterns. If you only want to extract URLs from a specific domain, you can add a domain check to the pattern. If you want only URLs with query parameters (to audit tracking parameters, for instance), you can require the presence of ? in the pattern.
Tips for Better Extraction Results
URLs in HTML often appear inside href="..." or src="..." attributes, surrounded by quotes and angle brackets. The extractor handles these correctly � it captures the URL content without the surrounding markup. However, URLs that are broken across lines (sometimes done in print media or email) may not be fully captured. If you're getting truncated URLs, try joining lines before extracting.
Watch out for URL-encoded characters. A space in a URL is typically encoded as %20 or +. The extractor preserves these encodings as-is, which is usually what you want � decoding them could change the URL's meaning. If you need decoded URLs, pass the extracted list through a URL decoder afterward.
When extracting from markdown-formatted text, watch for inline links like [text](url) and reference-style links like [text][ref]. The extractor captures the URL portion of inline links correctly. For reference-style links, you'll need to resolve the reference first � the extractor doesn't perform markdown parsing, it just finds URL patterns.
Frequently Asked Questions
http:// and https://. These two schemes cover the vast majority of URLs encountered in everyday text. FTP, mailto, telnet, file, and other schemes are excluded because they frequently appear in contexts where you don't want them extracted � for instance, mailto: links mixed in with regular email addresses.%20 for spaces or %E2%9C%93 for checkmarks) are extracted intact. The extractor doesn't decode them because encoding is part of the URL's canonical form � decoding could produce characters that break downstream processing. Decode separately if you need the human-readable version.<a href="..."> tags, <img src="..."> attributes, and inline styles with url() references. The extractor pulls the URL values without the surrounding markup. It also handles relative URLs � though these will be extracted as-is (e.g., /about), not resolved against a base URL.) and is followed by more text, the closing parenthesis might be interpreted as the URL's end. For most URLs, the extraction is accurate. If you notice truncation, check the original text for unusual delimiters around the URL.http:// or https://. Be aware that some JavaScript URLs might include template literals or escaped characters that make them look slightly different from their runtime values.https://??.jp) use Unicode characters in the domain portion. The extractor primarily targets ASCII URLs, which represent the overwhelming majority of URLs in circulation. IDN domains that are punycode-encoded (converted to xn-- format) are captured normally. For raw Unicode domains, you may need a pattern with explicit Unicode character class support.? character. This is useful for auditing tracking parameters (UTM codes), identifying API endpoints (which often use query parameters for authentication), or finding search functionality on a website./about or /api/users) are extracted if they appear after a scheme-prefixed URL or within a text block where the pattern can anchor. However, relative URLs without a leading slash or those using ../ notation may not be captured because they don't look like complete URLs to the pattern. For comprehensive extraction from HTML, consider using the rendered text rather than the raw source.