diff --git a/content/en/docs/21.0/user-guides/schema-changes/revertible-migrations.md b/content/en/docs/21.0/user-guides/schema-changes/revertible-migrations.md
index 71959cf0d..8980378ae 100644
--- a/content/en/docs/21.0/user-guides/schema-changes/revertible-migrations.md
+++ b/content/en/docs/21.0/user-guides/schema-changes/revertible-migrations.md
@@ -224,7 +224,7 @@ mysql> select * from t;
 
 Revert for `CREATE` and `DROP` are implemented similarly for all online strategies.
 
-- The revert for a `CREATE` DDL is to rename the table away and into a [table lifecycle](../table-lifecycle/) name, rather than actually `DROP` it. This keeps th etale safe for a period of time, and makes it possible to reinstate the table, populated with all data, via a 2nd revert.
+- The revert for a `CREATE` DDL is to rename the table away and into a [table lifecycle](../table-lifecycle/) name, rather than actually `DROP` it. This keeps the table safe for a period of time, and makes it possible to reinstate the table, populated with all data, via a 2nd revert.
 - The revert for a `DROP` relies on the fact that Online DDL `DROP TABLE` does not, in fact, drop the table, but actually rename it away. Thus, reverting the `DROP` is merely a `RENAME` back into its original place.
 - The revert for `ALTER` is only available for `vitess` strategy (formerly called `online`), implemented by `VReplication`. VReplication keep track of a DDL migration by writing down the GTID position through the migration flow. In particular, at time of cut-over and when tables are swapped, VReplication notes the _final_ GTID pos for the migration.
   When a revert is requested, Vitess computes a new VReplication rule/filter for the new stream. It them copies the _final_ GTID pos from the reverted migration, and instructs VReplication to resume from that point.
diff --git a/content/en/docs/22.0/user-guides/schema-changes/revertible-migrations.md b/content/en/docs/22.0/user-guides/schema-changes/revertible-migrations.md
index 71959cf0d..8980378ae 100644
--- a/content/en/docs/22.0/user-guides/schema-changes/revertible-migrations.md
+++ b/content/en/docs/22.0/user-guides/schema-changes/revertible-migrations.md
@@ -224,7 +224,7 @@ mysql> select * from t;
 
 Revert for `CREATE` and `DROP` are implemented similarly for all online strategies.
 
-- The revert for a `CREATE` DDL is to rename the table away and into a [table lifecycle](../table-lifecycle/) name, rather than actually `DROP` it. This keeps th etale safe for a period of time, and makes it possible to reinstate the table, populated with all data, via a 2nd revert.
+- The revert for a `CREATE` DDL is to rename the table away and into a [table lifecycle](../table-lifecycle/) name, rather than actually `DROP` it. This keeps the table safe for a period of time, and makes it possible to reinstate the table, populated with all data, via a 2nd revert.
 - The revert for a `DROP` relies on the fact that Online DDL `DROP TABLE` does not, in fact, drop the table, but actually rename it away. Thus, reverting the `DROP` is merely a `RENAME` back into its original place.
 - The revert for `ALTER` is only available for `vitess` strategy (formerly called `online`), implemented by `VReplication`. VReplication keep track of a DDL migration by writing down the GTID position through the migration flow. In particular, at time of cut-over and when tables are swapped, VReplication notes the _final_ GTID pos for the migration.
   When a revert is requested, Vitess computes a new VReplication rule/filter for the new stream. It them copies the _final_ GTID pos from the reverted migration, and instructs VReplication to resume from that point.