Yes: WireGuard® is safe for what it is designed to do, which is to carry your traffic to a server you have chosen so that nobody in between can read or alter it. The limits below are real, published by the project itself, and none of them is a hole in that promise. The risk that matters most is not in the protocol at all.
What "safe" means for a VPN protocol
Three things. Confidentiality: nobody between your phone and the server can read the traffic. Integrity: nobody can change it in transit without the change being detected and the packet discarded. Authentication: your phone is talking to the server it thinks it is, and the server knows which key it is talking to. A protocol that delivers all three is doing its job. Whether the server at the far end is trustworthy is a different question, covered at the end.
What has been proved
WireGuard's handshake is built on the Noise protocol framework, and the project publishes formal verification of the protocol: machine-checked proofs that the handshake provides the properties above, including forward secrecy, so that a key stolen tomorrow does not decrypt traffic captured today. Very few VPN protocols have that. The original paper describes the design and the reasoning behind each choice.
Forward secrecy, in one paragraph
The property people most often mean by "safe" without naming it is this: if someone records your encrypted traffic today and steals a key tomorrow, can they go back and read what they recorded? With WireGuard, no. Each session's traffic keys are derived during the handshake from fresh, short-lived values, and the handshake repeats about every two minutes, so a compromised long-term key unlocks nothing that was captured before. Recorded ciphertext stays ciphertext. That is forward secrecy, and it is one of the properties the published proofs cover.
Why a small codebase is a safety feature
Proofs cover the design. Code review covers the implementation, and the implementation is small enough that it has actually been reviewed: a few thousand lines, accepted into the Linux kernel after scrutiny from the people who maintain it. Bugs in cryptographic software historically live in the parts nobody read. WireGuard has very few parts nobody read.
Size also changes what a bug can be. A protocol that negotiates between dozens of cipher suites can be tricked into choosing a weak one; several well-known attacks on older VPN and TLS stacks worked exactly that way. WireGuard has one suite and no negotiation, so that whole class of attack has nothing to attack. If one of its primitives is ever broken, the fix is a new protocol version, not a configuration flag that some servers forget to set.
What "safe" does not cover
A tunnel protects the path, not the endpoints. WireGuard does nothing about a malicious app on your phone, a phishing page you log in to, or a website that already knows who you are because you signed in. It also does not hide your traffic from the VPN server, which decrypts it in order to send it onward. Anyone who tells you a VPN protocol makes you safe online, full stop, is selling something. It makes one specific thing safe: the wire between you and a server you chose.
What are the downsides of using WireGuard VPN?
Five, and the project lists them itself. It does not disguise its traffic, so an observer can tell you are using a VPN. Its cryptography is fixed rather than negotiated, which is safer but means an upgrade needs a new version, not a setting. It needs keys managed for it, which is why a consumer app has to do that for you. It is not post-quantum by default. And while you are connected, the server holds your current address in memory, because it must send packets back.
Each of these is on the Known Limitations page. The last one deserves a plain sentence: any VPN server knows where to send your packets while you are connected. WireGuard neither adds to that nor removes it; the question is only whether the operator writes it down, and for how long.
Is WireGuard compromised?
No. There is no known break of the protocol, and the design has published proofs behind it. When a VPN using WireGuard is compromised, the failure is at the operator: a server that logs more than it says, a company that sells traffic, a key that was handled badly. The protocol cannot protect you from the people running it.
Which is safer, WireGuard or OpenVPN?
Both are sound when configured well, and neither has a known break. WireGuard is smaller to audit, fixes its cryptography to modern choices, and has formal proofs; OpenVPN is older, far larger, more configurable, and can be made to look like ordinary HTTPS traffic, which WireGuard cannot. For a phone, where battery and reconnecting on the move matter, WireGuard is the better fit. For hiding that a VPN is in use at all, OpenVPN has a tool WireGuard lacks.
The risk that matters: the operator
Everything above is about the tunnel. The tunnel ends at a server, and the server decrypts your traffic, because that is what sending it onward requires. So the safety question you can actually act on is not "is WireGuard safe" but "what does this operator keep". A protocol with proofs behind it carries traffic to a company you still have to judge.
NetCloak's answer is short enough to quote in full, and it is the same paragraph on every page and in the privacy policy:
We do not log the sites you visit, your DNS queries, or anything else inside the tunnel. We cannot read it. We keep a small record while a session is running, deleted when the session ends. Operational logs that include your IP address are kept for no more than two days, then deleted. A VPN is not invisibility: it changes where your traffic joins the public internet, not what you do once it gets there.
The field-by-field version, including what the server holds while a session runs and who else touches data, is on the transparency page. Read that before you trust any VPN, this one included.