diff --git a/docs/cookbook/cb-02-inline-styles tip.md b/docs/cookbook/cb-02-inline-styles tip.md
index a4a30169ba..39d6f72ddd 100644
--- a/docs/cookbook/cb-02-inline-styles tip.md
+++ b/docs/cookbook/cb-02-inline-styles tip.md
@@ -19,4 +19,4 @@ var divStyle = {
React.renderComponent(
Hello World!
, mountNode);
```
-Style keys are camelCased in order to be consistent with accessing the properties using node.style.___ in DOM. This also explains why WebkitTransition has an uppercase 'W'.
+Style keys are camelCased in order to be consistent with accessing the properties using node.style.___ in DOM. This also explains why WebkitTransition has an uppercase "W".
diff --git a/docs/cookbook/cb-02-inline-styles.md b/docs/cookbook/cb-02-inline-styles.md
index 388620ec45..4dd44d05cb 100644
--- a/docs/cookbook/cb-02-inline-styles.md
+++ b/docs/cookbook/cb-02-inline-styles.md
@@ -24,4 +24,4 @@ React.renderComponent(Hello World!
, mountNode);
```
### Discussion
-Style keys are camelCased in order to be consistent with accessing the properties using `node.style.___` in DOM. This also explains why `WebkitTransition` has an uppercase 'W'.
+Style keys are camelCased in order to be consistent with accessing the properties using `node.style.___` in DOM. This also explains why `WebkitTransition` has an uppercase "W".
diff --git a/docs/cookbook/cb-05-jsx-root-node-count tip.md b/docs/cookbook/cb-05-jsx-root-node-count tip.md
index 86a49a108a..44e351d414 100644
--- a/docs/cookbook/cb-05-jsx-root-node-count tip.md
+++ b/docs/cookbook/cb-05-jsx-root-node-count tip.md
@@ -5,6 +5,6 @@ layout: docs
permalink: jsx-root-node-count-tip.html
---
-Currently in `render`, you can only return one node; if you have, say, a list of divs to return, you must wrap your components within, say, one big `div` or `span` (or any other component).
+Currently in `render`, you can only return one node; if you have, say, a list of `div`s to return, you must wrap your components within, say, one big `div` or `span` (or any other component).
Don't forget that JSX compiles into regular js, and returning two functions doesn't really make syntactic sense.
diff --git a/docs/cookbook/cb-08-controlled-input-null-value tip.md b/docs/cookbook/cb-08-controlled-input-null-value tip.md
index 2febcaf76c..83b252b1a5 100644
--- a/docs/cookbook/cb-08-controlled-input-null-value tip.md
+++ b/docs/cookbook/cb-08-controlled-input-null-value tip.md
@@ -7,7 +7,7 @@ permalink: controlled-input-null-value-tip.html
With a controlled input component, specifying a `value` prevents the user from changing the input unless you desire so (more info [here](forms.html)).
-You might have ran into a problem where you specified a `value` but the input can still be changed. In this case, you might have accidentally set your `value` to `undefined` or `null`. The snippet below shows this phenomenon; after a second, the text can be edited.
+You might have run into a problem where you specified a `value` but the input can still be changed. In this case, you might have accidentally set your `value` to `undefined` or `null`. The snippet below shows this phenomenon; after a second, the text can be edited.
```js
/** @jsx React.DOM */
diff --git a/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting-tip.md b/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting-tip.md
index d40fc0df1a..283cd6fbe0 100644
--- a/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting-tip.md
+++ b/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting-tip.md
@@ -5,6 +5,6 @@ layout: docs
permalink: componentWillReceiveProps-not-triggered-after-mounting-tip.html
---
-`componentWillReceiveProps` isn't triggered after the node is put on scene. This is by design. Checkout [other lifecycle methods](component-specs.html) for the one that suits your needs.
+`componentWillReceiveProps` isn't triggered after the node is put on scene. This is by design. Check out [other lifecycle methods](component-specs.html) for the one that suits your needs.
The reason for that is because `componentWillReceiveProps` often handles the logic of comparing with the old props and act upon changes; not triggering it at mounting, where there are no old props, clearly defines what the method should do.
diff --git a/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting.md b/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting.md
index 1b42a38d16..c9254504af 100644
--- a/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting.md
+++ b/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting.md
@@ -9,7 +9,7 @@ permalink: componentWillReceiveProps-not-triggered-after-mounting.html
`componentWillReceiveProps` isn't triggered after the node is put on scene.
### Solution
-This is by design. Checkout [other lifecycle methods](component-specs.html) for the one that suits your needs.
+This is by design. Check out [other lifecycle methods](component-specs.html) for the one that suits your needs.
### Discussion
`componentWillReceiveProps` often handles the logic of comparing with the old props and act upon changes; not triggering it at mounting, where there are no old props, clearly defines what the method should do.