diff --git a/docs/graphql/manual/auth/authentication/index.rst b/docs/graphql/manual/auth/authentication/index.rst
index bd3deed59f1..1bb6a9b2488 100644
--- a/docs/graphql/manual/auth/authentication/index.rst
+++ b/docs/graphql/manual/auth/authentication/index.rst
@@ -22,7 +22,7 @@ Authentication options
 Hasura supports two modes of authentication configuration:
 
 1) **Webhook**: Your auth server exposes a webhook that is used to authenticate all incoming requests
-   to the Hasura GraphQL engine server and to get metadata about the request to evaluate access control
+   to the Hasura GraphQL engine server and to get metadata about the request, to evaluate access control
    rules. Here's how a GraphQL request is processed in webhook mode:
 
    .. thumbnail:: ../../../../img/graphql/manual/auth/auth-webhook-overview.png
diff --git a/docs/graphql/manual/auth/authentication/jwt.rst b/docs/graphql/manual/auth/authentication/jwt.rst
index 0eb364b9471..8113b9fd197 100644
--- a/docs/graphql/manual/auth/authentication/jwt.rst
+++ b/docs/graphql/manual/auth/authentication/jwt.rst
@@ -12,7 +12,7 @@ Introduction
 You can configure the GraphQL engine to use JWT authorization mode to authorize all incoming requests to the Hasura GraphQL engine server.
 
 The idea is that your auth server will return JWT tokens, which are decoded and
-verified by the GraphQL engine to authorize and get metadata about the request
+verified by the GraphQL engine, to authorize and get metadata about the request
 (``x-hasura-*`` values).
 
 
@@ -53,9 +53,9 @@ When your auth server generates the JWT, the custom claims in the JWT **must con
 the following:
 
 1. A ``x-hasura-default-role`` field : indicating the default role of that user i.e. the role that will be
-   used in case ``x-hasura-role`` header is not passed
+   used in case ``x-hasura-role`` header is not passed.
 2. A ``x-hasura-allowed-roles`` field : a list of allowed roles for the user i.e. acceptable values of the
-   ``x-hasura-role`` header
+   ``x-hasura-role`` header.
 
 The claims in the JWT can have other ``x-hasura-*`` fields where their values
 can only be strings. You can use these ``x-hasura-*`` fields in your
@@ -159,7 +159,7 @@ JWTs). The URL **must** publish the JWKs in the standard format as described in
 https://tools.ietf.org/html/rfc7517.
 
 This is an optional field. You can also provide the key (certificate, PEM
-encoded public key) as string as well - under the ``key`` field.
+encoded public key) as a string - under the ``key`` field.
 
 **Rotating JWKs**:
 
@@ -177,7 +177,7 @@ JWKs are not refreshed.
 
 ``claims_namespace``
 ^^^^^^^^^^^^^^^^^^^^
-This is an optional field. You can specify the key name
+This is an optional field. You can specify the key name,
 inside which the Hasura specific claims will be present, e.g. ``https://mydomain.com/claims``.
 
 **Default value** is: ``https://hasura.io/jwt/claims``.
@@ -191,8 +191,8 @@ This is an optional field, with only the following possible values:
 
 Default is ``json``.
 
-This is to indicate that if the Hasura specific claims are a regular JSON object
-or stringified JSON.
+This is to indicate whether the Hasura specific claims are a regular JSON object
+or a stringified JSON.
 
 This is required because providers like AWS Cognito only allow strings in the
 JWT claims. `See #1176 <https://github.com/hasura/graphql-engine/issues/1176>`_.
@@ -272,8 +272,8 @@ or
    the ``aud`` claim from the JWT is also checked during verification. Not doing
    this check will allow JWTs issued for other tenants to be valid as well.
 
-   In these cases, you **MUST** set the ``audience`` field to appropriate value.
-   Failing to do is a major security vulnerability.
+   In these cases, you **MUST** set the ``audience`` field to the appropriate value.
+   Failing to do so is a major security vulnerability.
 
 
 ``issuer``
@@ -323,7 +323,7 @@ The ``key`` is the actual shared secret, which is used by Hasura and the externa
 RSA based
 +++++++++
 If your auth server is using RSA to sign JWTs, and is using a 512-bit key,
-the JWT config needs to have the only the public key.
+the JWT config only needs to have the public key.
 
 **Example 1**: public key in PEM format (not OpenSSH format):
 
@@ -387,7 +387,7 @@ Setting audience check
 ^^^^^^^^^^^^^^^^^^^^^^
 Certain JWT providers share JWKs between multiple tenants (like Firebase). They use the ``aud`` claim of JWT to specify the intended tenant for the JWT. Setting the ``audience`` field in the Hasura JWT configuration will make sure that the ``aud`` claim from the JWT is also checked during verification. Not doing this check will allow JWTs issued for other tenants to be valid as well.
 
-In these cases, you **MUST** set the ``audience`` field to appropriate value. Failing to do is a major security vulnerability.
+In these cases, you **MUST** set the ``audience`` field to appropriate value. Failing to do so is a major security vulnerability.
 
 
 Popular providers and known issues