Check slug uniqueness and format

This tool first enforces a predictable format made from lowercase letters, digits, and single hyphens, then compares the valid proposal with the existing slugs you provide. Invalid formatting produces an error even when the same text also appears in the list, so callers never mistake a malformed value for an ordinary naming collision. Valid results clearly report whether the slug is unique and whether an exact collision was found.

Validate the slug before checking availability

A uniqueness result is useful only when the proposed value can safely become part of a URL. Enter the candidate in the slug field and provide the slugs already used by your site, application, or content store. The checker accepts lowercase English letters from a to z, digits from 0 to 9, and hyphens placed between nonempty groups. It rejects uppercase letters, spaces, underscores, punctuation, leading or trailing hyphens, and repeated hyphens. This strict order matters: format validation happens before membership testing. If an invalid candidate also exists in the supplied list, the response is still an invalid-input error, not a normal collision result. That behavior prevents a publishing workflow from approving malformed routes merely because it knows they have been used before. It also gives integrations one stable rule to enforce at form submission, during bulk imports, and immediately before deployment. Keep the candidate under the documented length limit and send the current collection as an array of strings; no hidden normalization changes what you submitted.

Interpret exact collision results correctly

For a correctly formatted candidate, the response includes the submitted slug, confirms that its format is valid, and reports two complementary booleans: unique and collision. A collision means the exact candidate string occurs at least once in the supplied existing-slug array. Unique is the logical opposite, making the result convenient for interfaces that enable a publish button as well as systems that branch on conflicts. Comparison is deliberately exact rather than approximate. The checker does not remove prefixes, decode URL escapes, trim list entries, singularize words, or decide that similar phrases represent the same page. For example, product-guide and product-guides remain different valid routes. Exact behavior keeps the answer deterministic and lets your application remain responsible for business rules such as reserved names, locale prefixes, redirects, or case-insensitive database constraints. Duplicate values inside the existing array do not change the outcome. The list is treated as the caller's current source of truth, so refresh it before checks when several editors or deployment jobs can claim routes concurrently.

Use the check in publishing and deployment workflows

Run the check as close as practical to the point where a route is reserved. In a content editor, you can validate after a title-derived slug is generated and repeat the check when the editor changes it. In a static-site build, collect output paths first, then test each proposed route against the paths already accepted. In an API or migration, treat invalid-input errors as data-quality failures that require correction, while treating a collision result as a naming decision that may be resolved with a suffix or a different phrase. The operation is deterministic, uses no network service, and stores nothing, so the same input always gives the same answer. That makes it appropriate for tests and repeatable build gates. However, it is a checker rather than a reservation service: another process can claim a slug after your list was read. Systems with concurrent writers should still enforce a unique database constraint or perform an atomic reservation when saving. Use this result for early feedback and clean errors, then rely on your authoritative store for the final guarantee.