URL

Report di validazione

Cos'è il Validatore URL?

Incolli una URL e ricevi un report strutturato: è ben formata, com'è fatto ogni componente e a cosa stare attento. Il validatore passa la URL attraverso il costruttore URL nativo del browser — che implementa lo standard WHATWG URL — e poi aggiunge sopra controlli per componente.

Una "URL valida" non è solo una che fa il parse. Una URL come http://10.0.0.5/admin?token=abc123 fa il parse senza problemi, ma ha tre cose che probabilmente vuoi segnalare: http:// al posto di https://, un IP letterale come host e un token nella query string. Il validatore le tira fuori tutte e tre come avvisi, separati dal verdetto pass/fail. Le regole di sintassi sottostanti vengono dalla RFC 3986; le considerazioni sui nomi degli host vengono dalla RFC 1034 e dall'esperienza operativa.

L'output è JSON, quindi puoi inviarlo in pipe a uno script di CI o a un log di debug. Tutto gira nel tuo browser — la URL non lascia mai la tua macchina. Se vuoi solo scomporre la URL in componenti senza il livello di validazione, usa invece l'URL Parser. I nomi di dominio internazionalizzati sono gestiti secondo le regole IDNA.

Come usare il Validatore URL

Tre passi. Ognuno corrisponde a un pulsante in questa pagina.

Incolla una URL o carica l'esempio

Lascia cadere una URL nel pannello di sinistra. Clicca Esempio per caricare una URL pulita, ben formata, con parametri codificati in percentuale:

https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active

Il validatore si aggiorna mentre digiti. Prova i casi limite: URL con http://, host con IP letterale, URL con credenziali, host a singolo label (senza TLD), domini Punycode. Ognuno fa scattare un avviso diverso.

Leggi il report

Il pannello di destra mostra un report JSON con tre campi di primo livello: isValid (la URL ha fatto parse), checks (stato per componente — protocollo, hostname, porta, pathname) e warnings (segnalazioni informative che non sono errori di sintassi ma probabilmente ti interessano).

Copia o scarica

Clicca Copia per mandare il report JSON negli appunti, o Scarica per salvarlo come .json. Minifica compatta il report su una riga sola se ti serve per una entry di log.

Quando lo useresti davvero

Audit di un file di config prima del deploy

La config del tuo servizio ha 40 URL — endpoint webhook, callback OAuth, integrazioni di terze parti. Una ha una password incorporata da un test dimenticato, due puntano ancora a host http:// di staging. Passarle una alla volta nel validatore le pesca tutte e tre prima del rilascio. Le dipendenze sul formato URL compaiono anche nella spec OAuth 2.0 per i redirect URI.

Revisionare URL inviate da utenti in un form

Un utente invia un campo "sito" che si rivela essere example — niente protocollo, niente TLD, solo una parola. O https://192.168.1.5 — sembra valida, fa parse valida, ma quasi sicuramente non vuoi renderizzarla come link al profilo. Il validatore segnala entrambe: avviso TLD-mancante sulla prima, avviso host-IP-letterale sulla seconda.

Diagnosticare perché un redirect fallisce

Il tuo callback OAuth restituisce 400 con "invalid redirect_uri". La URL sembra a posto nel browser. La incolli nel validatore e lo vedi: il path contiene uno spazio letterale e il tuo provider di auth confronta le stringhe byte per byte dopo la canonicalizzazione. L'avviso ("path contains unencoded space") era la risposta.

Individuare un disallineamento Punycode vs Unicode

Ti aspettavi di vedere münchen.example.com nel report e invece hai visto xn--mnchen-3ya.example.com. È la forma Punycode — quella che viaggia sul filo — e il validatore la segnala così sai che l'input originale aveva caratteri non-ASCII. Utile quando l'utente di un bug report ha copiato e incollato una URL da un dominio IDN.

Domande frequenti

Cosa significa "valida" qui in concreto?

Due livelli. isValid: true significa che il costruttore URL del browser accetta l'input — ossia la sintassi è ben formata secondo lo standard WHATWG URL. warnings è separato: cose sintatticamente valide ma probabilmente non quel che vuoi (protocollo non sicuro, IP letterale, credenziali incorporate, TLD mancante, ecc.). Una URL può essere valida e avere comunque avvisi.

Controlla se la URL effettivamente risolve a qualcosa?

No — richiederebbe una richiesta di rete, e questo strumento gira interamente nel tuo browser senza chiamate uscenti. Il validatore controlla solo sintassi ed euristiche di superficie. Per controlli di raggiungibilità usa curl -I o uno strumento di uptime dedicato.

Perché http://example.com viene segnalato come avviso?

Perché nel 2026 una URL in chiaro è quasi sempre un errore — i browser moderni avvisano gli utenti prima di inviare form via http://, l'articolo "why HTTPS matters" di Google copre la versione lunga, e i domini con HSTS preload si rifiutano del tutto di caricare in HTTP. L'avviso è informativo; se davvero intendi http:// (intranet legacy, dev locale), ignoralo.

E le URL relative tipo /api/orders?

Il costruttore URL ha bisogno di una URL assoluta — senza una base, non può determinare il protocollo o l'host. Il validatore restituisce isValid: false con un errore chiaro in quel caso. Per validare una URL relativa, premettile prima una base come https://example.com.

Le credenziali nelle URL sono sempre sbagliate?

Quasi sempre. La RFC 3986 §3.2.1 nota che le credenziali nelle URL sono deprecate per motivi di sicurezza. Finiscono nella cronologia del browser, nei log di accesso del server e nelle cache dei proxy. I browser moderni le tolgono in silenzio quando incolli dagli appunti. Il validatore le segnala così hai una traccia esplicita prima che colino in qualche posto dove non dovrebbero.

Si occupa dei domini IDN?

Sì — il validatore annota se l'hostname è in forma Punycode (xn--...) o in ASCII puro. I browser possono mostrare la forma Unicode all'utente trasmettendo però la forma Punycode sul filo, ed è da lì che nascono gli attacchi omografici IDN. Far emergere il Punycode è un segnale piccolo ma utile.

Altri strumenti URL & JSON

La validazione è un'operazione. Ecco cosa si abbina naturalmente: