diff --git a/README.md b/README.md
index a9149bfff611e084857df624a19ca95f6dbeb46a..02cb726aea4c7b22c424afe413b6b8c75a863885 100644
--- a/README.md
+++ b/README.md
@@ -115,30 +115,30 @@ the same thing. Just compare the godoc of
 [nhooyr/websocket](https://godoc.org/nhooyr.io/websocket) with
 [gorilla/websocket](https://godoc.org/github.com/gorilla/websocket) side by side.
 
-The API for nhooyr/websocket has been designed such that there is only one way to do things.
+The API for nhooyr.io/websocket has been designed such that there is only one way to do things.
 This makes it easy to use correctly. Not only is the API simpler, the implementation is
 only 2200 lines whereas gorilla/websocket is at 3500 lines. That's more code to maintain,
 more code to test, more code to document and more surface area for bugs.
 
-Moreover, nhooyr/websocket supports newer Go idioms such as context.Context.
+Moreover, nhooyr.io/websocket supports newer Go idioms such as context.Context.
 It also uses net/http's Client and ResponseWriter directly for WebSocket handshakes.
 gorilla/websocket writes its handshakes to the underlying net.Conn.
 Thus it has to reinvent hooks for TLS and proxies and prevents support of HTTP/2.
 
-Some more advantages of nhooyr/websocket are that it supports concurrent writes and
+Some more advantages of nhooyr.io/websocket are that it supports concurrent writes and
 makes it very easy to close the connection with a status code and reason.
 
 The ping API is also nicer. gorilla/websocket requires registering a pong handler on the Conn
-which results in awkward control flow. With nhooyr/websocket you use the Ping method on the Conn
+which results in awkward control flow. With nhooyr.io/websocket you use the Ping method on the Conn
 that sends a ping and also waits for the pong.
 
 Additionally, nhooyr.io/websocket can compile to [Wasm](https://godoc.org/nhooyr.io/websocket#hdr-Wasm) for the browser.
 
-In terms of performance, the differences mostly depend on your application code. nhooyr/websocket
+In terms of performance, the differences mostly depend on your application code. nhooyr.io/websocket
 reuses message buffers out of the box if you use the wsjson and wspb subpackages.
-As mentioned above, nhooyr/websocket also supports concurrent writers.
+As mentioned above, nhooyr.io/websocket also supports concurrent writers.
 
-The only performance con to nhooyr/websocket is that it uses one extra goroutine to support
+The only performance con to nhooyr.io/websocket is that it uses one extra goroutine to support
 cancellation with context.Context. This costs 2 KB of memory which is cheap compared to
 the benefits.
 
@@ -159,11 +159,11 @@ and clarity.
 
 This library is fantastic in terms of performance. The author put in significant
 effort to ensure its speed and I have applied as many of its optimizations as
-I could into nhooyr/websocket. Definitely check out his fantastic [blog post](https://medium.freecodecamp.org/million-websockets-and-go-cc58418460bb)
+I could into nhooyr.io/websocket. Definitely check out his fantastic [blog post](https://medium.freecodecamp.org/million-websockets-and-go-cc58418460bb)
 about performant WebSocket servers.
 
 If you want a library that gives you absolute control over everything, this is the library.
-But for 99.9% of use cases, nhooyr/websocket will fit better. It's nearly as performant
+But for 99.9% of use cases, nhooyr.io/websocket will fit better. It's nearly as performant
 but much easier to use.
 
 ## Contributing