FIELD NOTE 016TypeScriptReviewed July 2026

URL Validation

Validates URL format including http/https protocols, domain, and path

ValidationURLRegexForm Validation

Implementation

Copy the complete example or adapt its typed interface to your project. Comments are kept inside the snippet so the intent travels with the code.

/**
 * Validate URL format
 * @param url URL to validate
 * @returns True if valid URL, false otherwise
 */
function isValidUrl(url: string): boolean {
  try {
    new URL(url);
    return true;
  } catch (e) {
    return false;
  }
}

// Alternative regex version (more flexible)
function isValidUrlRegex(url: string): boolean {
  const re = /^(https?://)?([da-z.-]+).([a-z.]{2,6})([/w.-]*)*/?$/;
  return re.test(url);
}

// Usage Example
console.log(isValidUrl('https://example.com')); // true
console.log(isValidUrl('example.com')); // false (requires protocol for URL constructor)
console.log(isValidUrlRegex('example.com')); // true (more flexible)

When to use it

↳

Great for validating user-provided URLs, link inputs, or API endpoint verification

Implementation note

Review the input assumptions and browser or runtime support before adopting a utility unchanged. Small helpers are easiest to maintain when their contract stays narrow.

Reasoning and trade-offs

How it works

The helper delegates parsing to the URL constructor and reports success when the input can form a supported absolute URL. Native parsing handles encoding and structural rules more reliably than a large handwritten expression.

What to watch for

URL accepts schemes that an application may not want, and a syntactically valid host may be unsafe or unreachable. Relative URLs require a base, while userinfo, localhost, private networks, and encoded redirects need security policy.

Production use

Use native parsing first, then explicitly allow protocols and host patterns for the feature. Server-side fetchers must also defend against SSRF, redirects, DNS changes, and private address ranges after validation.

Before you ship

Confirm the input contract with tests that cover empty, invalid, boundary, and representative real-world values before sharing the helper across a codebase.
Keep the function focused on one responsibility and name any project-specific policy explicitly instead of hiding it inside a generic-looking utility.
Measure behavior in the browsers or runtime versions your product supports, especially when timing, storage, DOM state, locale, or network access is involved.
Document the return type, mutation behavior, failure mode, and performance characteristics beside the call site so future maintainers can evaluate changes safely.
Compare the example with current official platform documentation when it relies on a browser API, language feature, or runtime behavior that may change over time.
If the helper crosses a trust boundary, validate again on the server and avoid treating browser-side checks, TypeScript annotations, or formatted output as a security guarantee.
Add a small regression test whenever a real edge case is discovered; concrete examples preserve the reason behind a guard more reliably than a general comment.

← PreviousEmail Address Validation Next →Convert String to CamelCase