diff --git a/docs/add_custom_data_claims.rst b/docs/add_custom_data_claims.rst
index 1265a26d..0a673b3b 100644
--- a/docs/add_custom_data_claims.rst
+++ b/docs/add_custom_data_claims.rst
@@ -19,7 +19,7 @@ decorator to register a callback function that will be called whenever a new JWT
is created, and return a dictionary of claims to add to that token. In the case
that both :meth:`~flask_jwt_extended.JWTManager.additional_claims_loader` and the
``additional_claims`` argument are used, both results are merged together, with ties
-going to the data suplied by the ``additional_claims`` argument.
+going to the data supplied by the ``additional_claims`` argument.
.. code-block:: python
diff --git a/docs/automatic_user_loading.rst b/docs/automatic_user_loading.rst
index 3dc3a38b..cc981394 100644
--- a/docs/automatic_user_loading.rst
+++ b/docs/automatic_user_loading.rst
@@ -3,13 +3,13 @@ Automatic User Loading
In most web applications it is important to have access to the user who is
accessing a protected route. We provide a couple callback functions that make
-this seemless while working with JWTs.
+this seamless while working with JWTs.
The first is :meth:`~flask_jwt_extended.JWTManager.user_identity_loader`, which
will convert any ``User`` object used to create a JWT into a JSON serializable format.
On the flip side, you can use :meth:`~flask_jwt_extended.JWTManager.user_lookup_loader`
-to automaticallly load your ``User`` object when a JWT is present in the request.
+to automatically load your ``User`` object when a JWT is present in the request.
The loaded user is available in your protected routes via :attr:`~flask_jwt_extended.current_user`.
Lets see an example of this while utilizing SQLAlchemy to store our users:
diff --git a/docs/basic_usage.rst b/docs/basic_usage.rst
index b50ea8bb..1aa736a0 100644
--- a/docs/basic_usage.rst
+++ b/docs/basic_usage.rst
@@ -64,7 +64,7 @@ We can see this in action using `HTTPie `_.
**Important**
-Remember to change the jwt secret key in your application, and ensure that it
+Remember to change the JWT secret key in your application, and ensure that it
is secure. The JWTs are signed with this key, and if someone gets their hands
-on it they will be able to create arbitraty tokens that are accepted by your
+on it they will be able to create arbitrary tokens that are accepted by your
web flask application.
diff --git a/docs/optional_endpoints.rst b/docs/optional_endpoints.rst
index 6d568383..b9e77ff0 100644
--- a/docs/optional_endpoints.rst
+++ b/docs/optional_endpoints.rst
@@ -2,7 +2,7 @@ Partially protecting routes
===========================
There may be cases where you want to use the same route regardless of if a JWT
-is present in the requst or not. In these situations, you can use
+is present in the request or not. In these situations, you can use
:func:`~flask_jwt_extended.jwt_required` with the ``optional=True`` argument. This
will allow the endpoint to be accessed regardless of if a JWT is sent in with
the request.
@@ -12,7 +12,7 @@ If no JWT is present, :func:`~flask_jwt_extended.get_jwt` and
:func:`~flask_jwt_extended.get_jwt_identity`, :attr:`~flask_jwt_extended.current_user`,
and :func:`~flask_jwt_extended.get_current_user` will return None.
-If a JWT that is expired or not verifyable is in the request, an error will be
+If a JWT that is expired or not verifiable is in the request, an error will be
still returned like normal.
diff --git a/docs/options.rst b/docs/options.rst
index cafc13ec..2c920106 100644
--- a/docs/options.rst
+++ b/docs/options.rst
@@ -20,7 +20,7 @@ General Options:
``["headers", "cookies"]``. The order of the list sets the precedence of
where JWTs will be looked for.
- This can be overriden on a per-route basis by using the ``locations``
+ This can be overridden on a per-route basis by using the ``locations``
argument in :func:`flask_jwt_extended.jwt_required`.
Default: ``"headers"``
@@ -61,7 +61,7 @@ General Options:
.. py:data:: JWT_ALGORITHM
Which algorithm to sign the JWT with. See `PyJWT `_
- for the available algorightms.
+ for the available algorithms.
Default: ``"HS256"``
@@ -69,7 +69,7 @@ General Options:
.. py:data:: JWT_DECODE_ALGORITHMS
Which algorithms to use when decoding a JWT. See `PyJWT `_
- for the available algorightms.
+ for the available algorithms.
By default this will always be the same algorithm that is defined in ``JWT_ALGORITHM``.
@@ -79,7 +79,7 @@ General Options:
.. py:data:: JWT_SECRET_KEY
The secret key used to encode and decode JWTs when using a symmetric signing
- algorightm (such as ``HS*``). It should be a long random string of bytes,
+ algorithm (such as ``HS*``). It should be a long random string of bytes,
although unicode is accepted too. For example, copy the output of this to
your config.
@@ -99,7 +99,7 @@ General Options:
.. py:data:: JWT_PRIVATE_KEY
The secret key used to encode JWTs when using an asymmetric signing
- algorightm (such as ``RS*`` or ``ES*``). The key must be in PEM format.
+ algorithm (such as ``RS*`` or ``ES*``). The key must be in PEM format.
**Do not reveal the secret key when posting questions or committing code.**
@@ -109,7 +109,7 @@ General Options:
.. py:data:: JWT_PUBLIC_KEY
The secret key used to decode JWTs when using an asymmetric signing
- algorightm (such as ``RS*`` or ``ES*``). The key must be in PEM format.
+ algorithm (such as ``RS*`` or ``ES*``). The key must be in PEM format.
Default: ``None``