diff --git a/.github/workflows/spell-check.yaml b/.github/workflows/spell-check.yaml
index 0b90c782..4ed2930c 100644
--- a/.github/workflows/spell-check.yaml
+++ b/.github/workflows/spell-check.yaml
@@ -14,6 +14,6 @@ jobs:
       uses: actions/checkout@v4
 
     - name: Check spelling of proposals
-      uses: crate-ci/typos@4550e7d4371fcf55649adfcda9b77716658504b1
+      uses: crate-ci/typos@9be36f97fdbe645ee9a12449fb13aca856c2516a
       with:
         config: ${{github.workspace}}/.github/_typos.toml
\ No newline at end of file
diff --git a/data/api/client-server/create_room.yaml b/data/api/client-server/create_room.yaml
index 3c04de00..2188a370 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 visibility of `public` equates to a preset of
+                    which preset to use. A visbility 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 d31607fb..73e607d1 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 standardise a way to transmit the token between clients.
+        might standarise 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 1182e100..32819193 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 standardised response format. Senders which receive
+        a more standarised 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 60064cfc..b79ce008 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 standardised response format. Senders which receive
+        a more standarised 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 89c462f8..e7b71408 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-delimited element names (`user_id`, not `UserID` or `user-id`).
+and underscore-deliminated element names (`user_id`, not `UserID` or `user-id`).
diff --git a/meta/releasing.md b/meta/releasing.md
index 83261385..92dd9be8 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 execution on spec release day. Plans are guides and not promises.
+and be ready for exeuction 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