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 <https://httpie.io/>`_.
 
 **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 <https://pyjwt.readthedocs.io/en/latest/algorithms.html>`_
-    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 <https://pyjwt.readthedocs.io/en/latest/algorithms.html>`_
-    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``