diff --git a/docs/api/workflows/tokens.md b/docs/api/workflows/tokens.md
index 517657932dd..6387ed01972 100644
--- a/docs/api/workflows/tokens.md
+++ b/docs/api/workflows/tokens.md
@@ -8,7 +8,7 @@ title: Tokens
 
 ## Feature Flag
 
-The Tokens Public API is available for Rancher v2.12.0 and later, and is enabled by default. It can be disabled by setting the `ext-tokens` feature flag to `false` as shown in the example `kubectl` command below:
+The Tokens Public API is available for Rancher v2.12.0 and later, and is enabled by default. You can disable the Tokens Public API by setting the `ext-tokens` feature flag to `false` as shown in the example `kubectl` command below:
 
 ```sh
 kubectl patch feature ext-tokens -p '{"spec":{"value":false}}'
@@ -16,7 +16,7 @@ kubectl patch feature ext-tokens -p '{"spec":{"value":false}}'
 
 ## Creating a Token
 
-Only a **valid and active** Rancher user can create a Token, otherwise you will get an error displayed (`Error from server (Forbidden)...`) when attempting to create a Token.
+Only a **valid and active** Rancher user can create a Token. Otherwise, you will get an error displayed (`Error from server (Forbidden)...`) when attempting to create a Token.
 
 ```bash
 kubectl create -o jsonpath='{.status.value}' -f -<<EOF
@@ -28,11 +28,11 @@ Error from server (Forbidden): error when creating "STDIN": tokens.ext.cattle.io
 
 A Token is always created for the user making the request. Attempting to create a Token for a different user, by specifying a different `spec.userID`, is forbidden and will fail.
 
-- The `spec.description` field can be set to an arbitrary human-readable description of the Tokens purpose. The default value is set to empty.
+- The `spec.description` field can be set to an arbitrary human-readable description of the Token's purpose. The default value is empty.
 
-- The `spec.kind` field can be set to the kind of Token. The value `session` indicates a login Token. All other values, including the default empty string, indicate some kind of derived Token.
+- The `spec.kind` field can be set to the kind of Token. The value `session` indicates a login Token. All other values, including the default empty string, indicate a kind of derived Token.
 
-- The `metadata.name` and `metadata.generateName` fields are ignored and the name of the new Token is automatically generated using the prefix `token-`.
+- The `metadata.name` and `metadata.generateName` fields are ignored, and the name of the new Token is automatically generated using the prefix `token-`.
 
 	```bash
 	kubectl create -o jsonpath='{.status.value}' -f -<<EOF
@@ -43,7 +43,7 @@ A Token is always created for the user making the request. Attempting to create
 	EOF
 	```
 
-- If the `spec.ttl` is not specified, the Token will be created with the expiration time defined in the `auth-token-max-ttl-minutes` setting. This is 90 days by default. If `spec.ttl` is specified, it should be greater than 0 and less than or equal to the value of the `auth-token-max-ttl-minutes` setting expressed in milliseconds.
+- If the `spec.ttl` is not specified, the Token is created with the expiration time defined in the `auth-token-max-ttl-minutes` setting. The default expiration time is 90 days. If `spec.ttl` is specified, it should be greater than 0 and less than or equal to the value of the `auth-token-max-ttl-minutes` setting expressed in milliseconds.
 
 	```bash
 	kubectl create -o jsonpath='{.status.value}' -f -<<EOF
@@ -56,7 +56,7 @@ A Token is always created for the user making the request. Attempting to create
 
 ## Listing Tokens
 
-Listing previously generated Tokens can be useful in order to clean up Tokens which are no longer needed (e.g., it was issued temporarily). Admins can list all Tokens, while regular users can only see their own.
+Listing previously generated Tokens can help clean up tokens that are no longer needed (e.g., they were issued temporarily). Admins can list all Tokens, while regular users can only see their own.
 
 ```sh
 kubectl get tokens.ext.cattle.io
@@ -105,7 +105,7 @@ token.ext.cattle.io "token-chjc9" deleted
 
 ## Updating a Token
 
-Only the metadata fields `spec.description`, `spec.ttl`, and `spec.enabled` can be updated. All other `spec` fields are immutable. Admins are able to extend the `spec.ttl` field, while regular users can only reduce the value.
+Only the metadata fields `spec.description`, `spec.ttl`, and `spec.enabled` can be updated. All other `spec` fields are immutable. Admins can extend the `spec.ttl` field, while regular users can only reduce the value.
 
 An example `kubectl` command to edit a Token:
 
diff --git a/versioned_docs/version-2.12/api/workflows/tokens.md b/versioned_docs/version-2.12/api/workflows/tokens.md
index 517657932dd..6387ed01972 100644
--- a/versioned_docs/version-2.12/api/workflows/tokens.md
+++ b/versioned_docs/version-2.12/api/workflows/tokens.md
@@ -8,7 +8,7 @@ title: Tokens
 
 ## Feature Flag
 
-The Tokens Public API is available for Rancher v2.12.0 and later, and is enabled by default. It can be disabled by setting the `ext-tokens` feature flag to `false` as shown in the example `kubectl` command below:
+The Tokens Public API is available for Rancher v2.12.0 and later, and is enabled by default. You can disable the Tokens Public API by setting the `ext-tokens` feature flag to `false` as shown in the example `kubectl` command below:
 
 ```sh
 kubectl patch feature ext-tokens -p '{"spec":{"value":false}}'
@@ -16,7 +16,7 @@ kubectl patch feature ext-tokens -p '{"spec":{"value":false}}'
 
 ## Creating a Token
 
-Only a **valid and active** Rancher user can create a Token, otherwise you will get an error displayed (`Error from server (Forbidden)...`) when attempting to create a Token.
+Only a **valid and active** Rancher user can create a Token. Otherwise, you will get an error displayed (`Error from server (Forbidden)...`) when attempting to create a Token.
 
 ```bash
 kubectl create -o jsonpath='{.status.value}' -f -<<EOF
@@ -28,11 +28,11 @@ Error from server (Forbidden): error when creating "STDIN": tokens.ext.cattle.io
 
 A Token is always created for the user making the request. Attempting to create a Token for a different user, by specifying a different `spec.userID`, is forbidden and will fail.
 
-- The `spec.description` field can be set to an arbitrary human-readable description of the Tokens purpose. The default value is set to empty.
+- The `spec.description` field can be set to an arbitrary human-readable description of the Token's purpose. The default value is empty.
 
-- The `spec.kind` field can be set to the kind of Token. The value `session` indicates a login Token. All other values, including the default empty string, indicate some kind of derived Token.
+- The `spec.kind` field can be set to the kind of Token. The value `session` indicates a login Token. All other values, including the default empty string, indicate a kind of derived Token.
 
-- The `metadata.name` and `metadata.generateName` fields are ignored and the name of the new Token is automatically generated using the prefix `token-`.
+- The `metadata.name` and `metadata.generateName` fields are ignored, and the name of the new Token is automatically generated using the prefix `token-`.
 
 	```bash
 	kubectl create -o jsonpath='{.status.value}' -f -<<EOF
@@ -43,7 +43,7 @@ A Token is always created for the user making the request. Attempting to create
 	EOF
 	```
 
-- If the `spec.ttl` is not specified, the Token will be created with the expiration time defined in the `auth-token-max-ttl-minutes` setting. This is 90 days by default. If `spec.ttl` is specified, it should be greater than 0 and less than or equal to the value of the `auth-token-max-ttl-minutes` setting expressed in milliseconds.
+- If the `spec.ttl` is not specified, the Token is created with the expiration time defined in the `auth-token-max-ttl-minutes` setting. The default expiration time is 90 days. If `spec.ttl` is specified, it should be greater than 0 and less than or equal to the value of the `auth-token-max-ttl-minutes` setting expressed in milliseconds.
 
 	```bash
 	kubectl create -o jsonpath='{.status.value}' -f -<<EOF
@@ -56,7 +56,7 @@ A Token is always created for the user making the request. Attempting to create
 
 ## Listing Tokens
 
-Listing previously generated Tokens can be useful in order to clean up Tokens which are no longer needed (e.g., it was issued temporarily). Admins can list all Tokens, while regular users can only see their own.
+Listing previously generated Tokens can help clean up tokens that are no longer needed (e.g., they were issued temporarily). Admins can list all Tokens, while regular users can only see their own.
 
 ```sh
 kubectl get tokens.ext.cattle.io
@@ -105,7 +105,7 @@ token.ext.cattle.io "token-chjc9" deleted
 
 ## Updating a Token
 
-Only the metadata fields `spec.description`, `spec.ttl`, and `spec.enabled` can be updated. All other `spec` fields are immutable. Admins are able to extend the `spec.ttl` field, while regular users can only reduce the value.
+Only the metadata fields `spec.description`, `spec.ttl`, and `spec.enabled` can be updated. All other `spec` fields are immutable. Admins can extend the `spec.ttl` field, while regular users can only reduce the value.
 
 An example `kubectl` command to edit a Token: