diff --git a/README.md b/README.md
index 6d796de..03ce266 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-# Responder: a familar HTTP Service Framework for Python
+# Responder: a familiar HTTP Service Framework for Python
 
 ![](https://github.com/kennethreitz/responder/raw/master/ext/Artboard%201%402x.png)
 
@@ -99,7 +99,7 @@ The primary concept here is to bring the nicities that are brought forth from bo
 - Automatic gzipped-responses (still working on that).
 - In addition to Falcon's `on_get`, `on_post`, etc methods, Responder features an `on_request` method, which gets called on every type of request, much like Requests.
 - WhiteNoise is built-in, for serving static files.
-- Waitress built-in as a production web server. I would have chosen Gunicorn, but it doesn't run on Windows. Plus, Waitress serves well to protect against slowloris attacks, making nginx unneccessary in production.
+- Waitress built-in as a production web server. I would have chosen Gunicorn, but it doesn't run on Windows. Plus, Waitress serves well to protect against slowloris attacks, making nginx unnecessary in production.
 - GraphQL support, via Graphene. The goal here is to have any GraphQL query exposable at any route, magically.
 
 
@@ -112,7 +112,7 @@ The primary concept here is to bring the nicities that are brought forth from bo
 ## Future Ideas
 
 - I want to be able to "mount" any WSGI app into a sub-route.
-- Cooke-based sessions are currently an afterthrought, as this is an API framework, but websites are APIs too.
+- Cooke-based sessions are currently an afterthought, as this is an API framework, but websites are APIs too.
 - Potentially support ASGI instead of WSGI. Will the tradeoffs be worth it? This is a question to ask. Procedural code works well for 90% use cases.
 - If frontend websites are supported, provide an official way to run webpack.