diff --git a/djadmin2/actions.py b/djadmin2/actions.py
index ac7b7828..31f3c0e5 100644
--- a/djadmin2/actions.py
+++ b/djadmin2/actions.py
@@ -137,7 +137,7 @@ def process_queryset(self):
 
 
 class DeleteSelectedAction(BaseListAction):
-    # TODO: Check that user has permission to delete all related obejcts.  See
+    # TODO: Check that user has permission to delete all related objects.  See
     # `get_deleted_objects` in contrib.admin.util for how this is currently
     # done.  (Hint: I think we can do better.)
 
diff --git a/djadmin2/views.py b/djadmin2/views.py
index dc37df38..52ff84b3 100644
--- a/djadmin2/views.py
+++ b/djadmin2/views.py
@@ -132,7 +132,7 @@ def post(self, request):
         if hasattr(action_callable, "process_queryset"):
             response = action_callable.as_view(queryset=queryset, model_admin=self.model_admin)(request)
         else:
-            # generate the reponse if a function.
+            # generate the response if a function.
             response = action_callable(request, queryset)
 
         if response is None:
@@ -204,7 +204,7 @@ def _modify_queryset_for_sort(self, queryset):
         # If we are sorting AND the field exists on the model
         sort_by = self.request.GET.get('sort', None)
         if sort_by:
-            # Special case when we are not explicityly displaying fields
+            # Special case when we are not explicitly displaying fields
             if sort_by == '-__str__':
                 queryset = queryset[::-1]
             try:
diff --git a/docs/ref/actions.rst b/docs/ref/actions.rst
index 3ec8243d..69fb76bb 100644
--- a/docs/ref/actions.rst
+++ b/docs/ref/actions.rst
@@ -48,7 +48,7 @@ The basic workflow of Django’s admin is, in a nutshell, “select an object, t
 
 In these cases, Django’s admin lets you write and register “actions” – simple functions that get called with a list of objects selected on the change list page.
 
-If you look at any change list in the admin, you’ll see this feature in action; Django ships with a “delete selected objects” action available to all models.  Using our sample models, let's pretend we wrote a blog article about Django and our mother put in a whole bunch of embarressing comments. Rather than cherry-pick the comments, we want to delete the whole batch.
+If you look at any change list in the admin, you’ll see this feature in action; Django ships with a “delete selected objects” action available to all models.  Using our sample models, let's pretend we wrote a blog article about Django and our mother put in a whole bunch of embarrassing comments. Rather than cherry-pick the comments, we want to delete the whole batch.
 
 In our blog/admin.py module we write:
 
diff --git a/docs/ref/meta.rst b/docs/ref/meta.rst
index e48cba3b..8d3e24d5 100644
--- a/docs/ref/meta.rst
+++ b/docs/ref/meta.rst
@@ -4,7 +4,7 @@ Django's Model._meta
 
 Currently django implements most of its behaviour that makes using models so
 nice using a metaclass. A metaclass is invoked when an actual class is created
-and can change that class' behaviour by adding or modifing its attributes and
+and can change that class' behaviour by adding or modifying its attributes and
 methods. This means that django is actually changing your model class at the
 moment when the ``models.py`` file of your app is loaded.
 
@@ -68,7 +68,7 @@ the `django documentation
 ``db_table``
     Contains the name of the database table used for this model. This is
     either what was set on ``Meta`` or defaults to a string that is built
-    from ``app_label`` and ``model_name`` seperated by an underscore. So for
+    from ``app_label`` and ``model_name`` separated by an underscore. So for
     example the ``db_table`` for ``django.contrib.auth.models.User`` is
     ``'auth_user'``.
 
diff --git a/docs/ref/permissions.rst b/docs/ref/permissions.rst
index 5b11403b..5a4e6267 100644
--- a/docs/ref/permissions.rst
+++ b/docs/ref/permissions.rst
@@ -78,7 +78,7 @@ method takes are pretty self explanatory:
 
 Based on these arguments should the ``has_permission`` method than return
 either ``True`` if the permission shall be granted or ``False`` if the access
-to the user shall be diened.
+to the user shall be denied.
 
 Here is an example implementation of a custom permission class:
 
@@ -214,7 +214,7 @@ So what we actually did here is that we just put the name of the
 ``ModelAdmin2`` that is used for the model you want to access between the
 ``permissions`` variable and the ``has_view_permission``. This name will be the
 app label followed by the model name in lowercase with an underscore in between
-for ordinary django models. That way you can break free of beeing limitted to
+for ordinary django models. That way you can break free of beeing limited to
 permission checks for the current ``ModelAdmin2``. But that doesn't help you
 either if you don't know from the beginning on which model admin you want to
 check the permissions. Imagine the admin's index page that should show a list
diff --git a/example/blog/tests/test_views.py b/example/blog/tests/test_views.py
index c52c119d..c6d3bc06 100644
--- a/example/blog/tests/test_views.py
+++ b/example/blog/tests/test_views.py
@@ -34,7 +34,7 @@ def test_view_ok(self):
 class UserListTest(BaseIntegrationTest):
 
     def test_search_users_m2m_group(self):
-        # This test should cause the distinct search path to exectue
+        # This test should cause the distinct search path to execute
         group = Group.objects.create(name="Test Group")
         self.user.groups.add(group)