DevTools Hub

Search tools

Search for a developer tool

WireGuard Config Validator

Validate a WireGuard .conf file — malformed keys, missing AllowedIPs, duplicate peers, and bad endpoints.

Part of the VPN Toolkit
Findings (1)
[Peer] #1 AllowedIPs includes 0.0.0.0/0 or ::/0 — all traffic is routed through this peer (full tunnel). Intentional for a VPN gateway, worth double-checking otherwise.
Parsed sections
[Interface]
  • privatekeykjOHaYFJ//Dk7HiDDhib6c45Cjf7/no4iCc5yyvZrAc=
  • address10.0.0.2/24
[Peer] #1
  • publickeyJgeHWCWPx6qF31iX5Uln8E29NvhFV32NF9tOZ2MO6kg=
  • allowedips0.0.0.0/0
  • endpointvpn.example.com:51820
  • persistentkeepalive25

What this does

Parses a WireGuard .conf file — [Interface] and one or more [Peer] sections — entirely in your browser, and flags the mistakes that normally only surface as a connection that silently fails to come up: a malformed key, a CIDR address missing its prefix length, a peer with no AllowedIPs, a duplicate peer key, or an Endpoint that isn't valid host:port syntax.

What it checks a key against

A WireGuard key — private, public, or preshared — is always 32 raw bytes, base64-encoded to exactly 44 characters ending in =. This tool decodes every key it finds and confirms that length, which catches the most common real mistake: pasting a truncated key, swapping a public key into the private key field, or leaving a placeholder value in place. It does not verify the key is a valid point on Curve25519 — that requires the actual key-generation math, not just format inspection.

FAQ

Does this tool verify that a key is actually a valid Curve25519 key?

No — it checks that a key is correctly formatted (44 base64 characters decoding to exactly 32 bytes), which catches the overwhelming majority of real mistakes: a truncated paste, a key from the wrong field swapped in, or a placeholder value never replaced. It doesn't verify the key lies on the Curve25519 curve, which requires the actual key generation math, not just format inspection.

Why does it flag 0.0.0.0/0 as informational instead of an error?

Routing all traffic through a peer's AllowedIPs is completely normal for a VPN gateway or exit node — it's the entire point of a full-tunnel setup. It's flagged only so a split-tunnel config that meant to list specific subnets and accidentally included 0.0.0.0/0 doesn't silently route everything by mistake.

Why does a missing PersistentKeepalive get flagged at all if it's optional?

It's genuinely optional and often unnecessary — a peer with a stable, non-NAT'd address doesn't need it. But it's the single most common fix for "WireGuard connects, then silently stops working after a few minutes," which happens when the peer is behind NAT or a stateful firewall that times out the mapping. It's informational, not an error, precisely because leaving it unset is often fine.

Can this tool validate a PresharedKey the same way?

Yes — a PresharedKey uses the identical format (44 base64 characters, 32 bytes) as a PrivateKey or PublicKey, so it's checked the same way when present. It's optional in WireGuard; adding one layers symmetric-key resistance on top of the Curve25519 exchange as a hedge against a future quantum-computing break of the asymmetric side.

Does this handle multiple [Peer] sections?

Yes — every [Peer] section in the file is validated independently and labeled by position (#1, #2, ...), and the tool specifically checks for duplicate PublicKey values across peers, which routes traffic ambiguously and is a common copy-paste mistake when adding a new peer from an existing one.

Try it yourself

For the full anatomy of a WireGuard config and what each field actually does, see WireGuard Config Explained. Routing everything through the VPN except a few subnets? VPN Split-Tunnel CIDR Calculator computes the exact AllowedIPs list for that.

Related tools