diff --git a/Memory-model.md b/Memory-model.md
index 66a4d78..b59584d 100644
--- a/Memory-model.md
+++ b/Memory-model.md
@@ -23,7 +23,7 @@ There are basically two approaches here:
 1. either you can predict the content of the object tree,
 2. or, you know how much memory is available.
 
-In the first case, you know some constraints on the object tree. For instance, let's say that your know in advance (and by that I mean "at compilation time") that you want to generate an object with 3 values, one of them being an array with 2 values, like the following:
+In the first case, you know some constraints on the object tree. For instance, let's say that you know in advance (and by that I mean "at compilation time") that you want to generate an object with 3 values, one of them being an array with 2 values, like the following:
 
     {"sensor":"gps","time":1351824120,"data":[48.756080,2.302038]}
 
@@ -38,14 +38,14 @@ The solution here is to determine how much memory is available, or in other word
 
 ### Why choosing fixed allocation?
 
-This fixed allocation approach may seem a bit strange, especially if your a desktop application developer used to dynamic allocation, but it make a lot of sense in an embedded context:
+This fixed allocation approach may seem a bit strange, especially if you are a desktop application developer used to dynamic allocation, but it makes a lot of sense in an embedded context:
 
 1. the code is smaller
 2. it uses less memory
 3. it doesn't create memory fragmentation
-4. it predictable
+4. it is predictable
 
-Don't forget that the memory is "freed" as soon as the `StaticJsonBuffer` is out of scope, like any other variable. It only hold the memory for a short amount of time.
+Don't forget that the memory is "freed" as soon as the `StaticJsonBuffer` is out of scope, like any other variable. It only holds the memory for a short amount of time.
 
 ## Dynamic memory allocation