diff --git a/googlemock/docs/v1_5/CookBook.md b/googlemock/docs/v1_5/CookBook.md
index 6da89fc2..f85bc3bf 100644
--- a/googlemock/docs/v1_5/CookBook.md
+++ b/googlemock/docs/v1_5/CookBook.md
@@ -2081,12 +2081,12 @@ versus
 
 ## Forcing a Verification ##
 
-When it's being destoyed, your friendly mock object will automatically
+When it's being destroyed, your friendly mock object will automatically
 verify that all expectations on it have been satisfied, and will
 generate [Google Test](http://code.google.com/p/googletest/) failures
 if not. This is convenient as it leaves you with one less thing to
 worry about. That is, unless you are not sure if your mock object will
-be destoyed.
+be destroyed.
 
 How could it be that your mock object won't eventually be destroyed?
 Well, it might be created on the heap and owned by the code you are
diff --git a/googlemock/docs/v1_6/CookBook.md b/googlemock/docs/v1_6/CookBook.md
index 46a2ea1f..5224661f 100644
--- a/googlemock/docs/v1_6/CookBook.md
+++ b/googlemock/docs/v1_6/CookBook.md
@@ -2212,12 +2212,12 @@ MockFoo::~MockFoo() {}
 
 ## Forcing a Verification ##
 
-When it's being destoyed, your friendly mock object will automatically
+When it's being destroyed, your friendly mock object will automatically
 verify that all expectations on it have been satisfied, and will
 generate [Google Test](http://code.google.com/p/googletest/) failures
 if not. This is convenient as it leaves you with one less thing to
 worry about. That is, unless you are not sure if your mock object will
-be destoyed.
+be destroyed.
 
 How could it be that your mock object won't eventually be destroyed?
 Well, it might be created on the heap and owned by the code you are
diff --git a/googlemock/docs/v1_7/CookBook.md b/googlemock/docs/v1_7/CookBook.md
index 60024075..94a9a485 100644
--- a/googlemock/docs/v1_7/CookBook.md
+++ b/googlemock/docs/v1_7/CookBook.md
@@ -2240,12 +2240,12 @@ MockFoo::~MockFoo() {}
 
 ## Forcing a Verification ##
 
-When it's being destoyed, your friendly mock object will automatically
+When it's being destroyed, your friendly mock object will automatically
 verify that all expectations on it have been satisfied, and will
 generate [Google Test](http://code.google.com/p/googletest/) failures
 if not. This is convenient as it leaves you with one less thing to
 worry about. That is, unless you are not sure if your mock object will
-be destoyed.
+be destroyed.
 
 How could it be that your mock object won't eventually be destroyed?
 Well, it might be created on the heap and owned by the code you are