diff --git a/data/api/client-server/create_room.yaml b/data/api/client-server/create_room.yaml
index 2188a370e..3c04de00d 100644
--- a/data/api/client-server/create_room.yaml
+++ b/data/api/client-server/create_room.yaml
@@ -209,7 +209,7 @@ paths:
                     based on a preset.
 
                     If unspecified, the server should use the `visibility` to determine
-                    which preset to use. A visbility of `public` equates to a preset of
+                    which preset to use. A visibility of `public` equates to a preset of
                     `public_chat` and `private` visibility equates to a preset of
                     `private_chat`.
                 is_direct:
diff --git a/data/api/client-server/login_token.yaml b/data/api/client-server/login_token.yaml
index 73e607d1d..d31607fb1 100644
--- a/data/api/client-server/login_token.yaml
+++ b/data/api/client-server/login_token.yaml
@@ -39,7 +39,7 @@ paths:
 
         In v1.7 of the specification, transmission of the generated token to an unauthenticated client is
         left as an implementation detail. Future MSCs such as [MSC3906](https://github.com/matrix-org/matrix-spec-proposals/pull/3906)
-        might standarise a way to transmit the token between clients.
+        might standardise a way to transmit the token between clients.
 
         The generated token MUST only be valid for a single login, enforced by the server. Clients which
         intend to log in multiple devices must generate a token for each.
diff --git a/data/api/server-server/joins-v2.yaml b/data/api/server-server/joins-v2.yaml
index 32819193b..1182e100e 100644
--- a/data/api/server-server/joins-v2.yaml
+++ b/data/api/server-server/joins-v2.yaml
@@ -27,7 +27,7 @@ paths:
         exception of the response format being fixed.
 
         This endpoint is preferred over the v1 API as it provides
-        a more standarised response format. Senders which receive
+        a more standardised response format. Senders which receive
         a 400, 404, or other status code which indicates this endpoint
         is not available should retry using the v1 API instead.
 
diff --git a/data/api/server-server/leaving-v2.yaml b/data/api/server-server/leaving-v2.yaml
index b79ce0083..60064cfcc 100644
--- a/data/api/server-server/leaving-v2.yaml
+++ b/data/api/server-server/leaving-v2.yaml
@@ -27,7 +27,7 @@ paths:
         exception of the response format being fixed.
 
         This endpoint is preferred over the v1 API as it provides
-        a more standarised response format. Senders which receive
+        a more standardised response format. Senders which receive
         a 400, 404, or other status code which indicates this endpoint
         is not available should retry using the v1 API instead.
 
diff --git a/meta/documentation_style.rst b/meta/documentation_style.rst
index e7b714089..89c462f84 100644
--- a/meta/documentation_style.rst
+++ b/meta/documentation_style.rst
@@ -191,4 +191,4 @@ Describing grammar
 
 Use  `RFC5234-style ABNF <https://datatracker.ietf.org/doc/html/rfc5234>`_ when describing
 the grammar for something in the spec, such as user IDs or server names. Use lowercase
-and underscore-deliminated element names (`user_id`, not `UserID` or `user-id`).
+and underscore-delimited element names (`user_id`, not `UserID` or `user-id`).
diff --git a/meta/releasing.md b/meta/releasing.md
index 92dd9be8b..832613858 100644
--- a/meta/releasing.md
+++ b/meta/releasing.md
@@ -31,7 +31,7 @@ day until the release has actually happened & blog post published.
 
 Once a release is scheduled, the SCT will begin planning what the next release is
 expected to look like. The plan should be included in the spec release blog post,
-and be ready for exeuction on spec release day. Plans are guides and not promises.
+and be ready for execution on spec release day. Plans are guides and not promises.
 
 A blog post for the SCT members to review should be ready at minimum 1 week before
 the target release date. 1-2 days before the release itself, the prerequisite steps