Fixing some typos

3 files changed, 5 insertions, 5 deletions

diff --git a/docs/oauth1/client.rst b/docs/oauth1/client.rst
index 2b3dfec..b209196 100644
--- a/docs/oauth1/client.rst
+++ b/docs/oauth1/client.rst
@@ -59,7 +59,7 @@ Using the Client
 
     * a dictionary
     * an iterable of 2-tuples
-    * a properly-formated x-www-url-formencoded string
+    * a properly-formatted x-www-url-formencoded string
 
 **RSA Signatures**
 
diff --git a/docs/oauth1/security.rst b/docs/oauth1/security.rst
index fa2180e..a1432a9 100644
--- a/docs/oauth1/security.rst
+++ b/docs/oauth1/security.rst
@@ -11,7 +11,7 @@ A few important facts regarding OAuth security
         nonce/timestamp pairs for each request, allowing an attacker who
         intercept your request to replay it later, overriding your initial
         request. **Server defaults to fail all requests which are not made over
-        HTTPS**, you can explicitely disable this using the enforce_ssl
+        HTTPS**, you can explicitly disable this using the enforce_ssl
         property.
 
     * **Tokens must be random**, OAuthLib provides a method for generating
@@ -19,7 +19,7 @@ A few important facts regarding OAuth security
         use it. If you decide to roll your own, use ``random.SystemRandom``
         which is based on ``os.urandom`` rather than the default ``random``
         based on the effecient but not truly random Mersenne Twister.
-        Predicatble tokens allow attackers to bypass virtually all defences
+        Predictable tokens allow attackers to bypass virtually all defences
         OAuth provides.
 
     * **Timing attacks are real** and more than possible if you host your
diff --git a/docs/oauth1/server.rst b/docs/oauth1/server.rst
index fec8e40..9364f8c 100644
--- a/docs/oauth1/server.rst
+++ b/docs/oauth1/server.rst
@@ -161,7 +161,7 @@ obtain an access token.
 **Authorization Verifier**:
     An unguessable unique string of characters. This code asserts that the user
     has given the client authorization to access the requested realms. It is
-    initial nil when the client obtains the request token in the first step, and
+    initially nil when the client obtains the request token in the first step, and
     set after user authorization is given in the second step::
 
         verifier = sqlalchemy.Column(sqlalchemy.String)
@@ -178,7 +178,7 @@ The user and realms will need to be transferred from the request token to the
 access token. It is possible that the list of authorized realms is smaller
 than the list of requested realms. Clients can observe whether this is the case
 by comparing the `oauth_realms` parameter given in the token reponse. This way
-of indicated change of realms is backported from OAuth2 scope behaviour and is
+of indicating change of realms is backported from OAuth2 scope behaviour and is
 not in the OAuth 1 spec.
 
 **Client**: