diff --git a/tutorial/01-nodes.osm b/tutorial/01-nodes.osm
index 34a1d4d..5b96654 100644
--- a/tutorial/01-nodes.osm
+++ b/tutorial/01-nodes.osm
@@ -29,12 +29,12 @@ If you define a bounding box using a fixed set of points, then the query will
 only ever use that geographic area. But sometimes you want to run a query over
 whatever section of the map you're currently looking at.
 
-The Overpass Turbo IDE provides a third way to define a bounding box. But automatically
+The Overpass Turbo IDE provides a third way to define a bounding box, by automatically
 inserting the coordinates for the current map view into your query.
 This is specified by including the "`{{box}}`" shortcut instead of the coordinates. Overpass Turbo will then adjust
 your query before its run.
 
-This won't happen if you submit a query directly to the API. Its only a feature of the IDE. But
+This won't happen if you submit a query directly to the API. It's only a feature of the IDE. But
 helpful when you're writing queries interactively.
 
 When should you use the different variations?
diff --git a/tutorial/02-node-output.osm b/tutorial/02-node-output.osm
index 5c761ea..860141d 100644
--- a/tutorial/02-node-output.osm
+++ b/tutorial/02-node-output.osm
@@ -44,7 +44,7 @@ node;
 
 //...and output data about those nodes
 
-//Outputing ids only means Overpass Turbo can't draw you a map,
+//Outputting ids only means Overpass Turbo can't draw you a map,
 //you'll just get some XML output
 out ids;
 
diff --git a/tutorial/10-the-default-set.osm b/tutorial/10-the-default-set.osm
index 34fdee7..1a97a62 100644
--- a/tutorial/10-the-default-set.osm
+++ b/tutorial/10-the-default-set.osm
@@ -22,7 +22,7 @@ and produce output from multiple named sets of results.
 */
 [bbox:-25.38653, 130.99883, -25.31478, 131.08938];
 
-//find nodes within out bounding box that have a name
+//find nodes within our bounding box that have a name
 //and write the result to the default set
 node["name"]->._;
 
diff --git a/tutorial/14-searching-by-polygon.osm b/tutorial/14-searching-by-polygon.osm
index bb6ae96..4f41962 100644
--- a/tutorial/14-searching-by-polygon.osm
+++ b/tutorial/14-searching-by-polygon.osm
@@ -3,8 +3,8 @@ OverpassQL supports searching for features within a polygon defined by a collect
 points.
 
 The `poly` filter accepts a single parameter. This must be a string value that
-contains an even number of latitude and longitude pairs. Collectively these
-coordinates should define a closed shape on the map.
+contains latitude and longitude pairs. Collectively these coordinates should define a
+closed shape on the map.
 
 This polygon is then used as the boundary for the query.
 
diff --git a/tutorial/16-ways-and-their-nodes.osm b/tutorial/16-ways-and-their-nodes.osm
index 9f87b9b..a10c0dd 100644
--- a/tutorial/16-ways-and-their-nodes.osm
+++ b/tutorial/16-ways-and-their-nodes.osm
@@ -5,7 +5,7 @@ their outline.
 In OverpassQL we do this using the "recurse down" statement "`>`".
 
 This statement takes an input set of elements and then finds any
-node (or way, or relation) that are a member of those elements.
+node (or way, or relation) that is a member of those elements.
 
 The members of a way are its nodes.
 
diff --git a/tutorial/17-ways-and-their-tags.osm b/tutorial/17-ways-and-their-tags.osm
index 0bd88e2..0910b76 100644
--- a/tutorial/17-ways-and-their-tags.osm
+++ b/tutorial/17-ways-and-their-tags.osm
@@ -6,7 +6,7 @@ That includes filtering them based on their tags. Or using them to search
 nearby on the map.
 
 The query below selects just those ways in our bounding box that have been
-tagged as a tourist attraction. As the time of writing, that results in a
+tagged as a tourist attraction. At the time of writing, that results in a
 single way which marks out the boundary of Uluṟu.
 
 See the query comments for other variations to try, including finding
diff --git a/tutorial/20-relations.osm b/tutorial/20-relations.osm
index 52701f7..9ade207 100644
--- a/tutorial/20-relations.osm
+++ b/tutorial/20-relations.osm
@@ -6,7 +6,7 @@ Relations are collections of nodes and ways. They describe logical groupings of
 objects that go beyond their basic spatial relationship. For example a relation
 can be used to describe:
 
-* a bus route, which connects a set of bus stop (nodes) and ways (the route)
+* a bus route, which connects a set of bus stops (nodes) and ways (the route)
 * an administrative boundary
 * a multipolygon, such as a collection of buildings that represent a single location
 
diff --git a/tutorial/22-areas.osm b/tutorial/22-areas.osm
index 7f26ed9..49fa25b 100644
--- a/tutorial/22-areas.osm
+++ b/tutorial/22-areas.osm
@@ -47,7 +47,7 @@ way(area);
 ```
 
 The `area` filter restricts the ways (or nodes, or relations) we're interested in
-to just those that within an area we've already found. This type of spatial query
+to just those within an area we've already found. This type of spatial query
 isn't normally available for ways and relations. I presume this is to limit the amount
 of indexing required to support this type of query.
 
@@ -55,12 +55,12 @@ The `area` query and the `area` filter both work with named sets. By default the
 with the default set (`_`). And this is what the example query uses.
 
 But an alternate way to write this example is to explicitly store the area we're
-interested in a named set. I find this a bit clearer in practice.
+interested in in a named set. I find this a bit clearer in practice.
 
 Here's how this would look, using a named set called `ourArea`:
 
 ```
-area["name"="Uluru-Kata Tjuta National Park"]->.ourArea;
+area["name"="Uluṟu-Kata Tjuṯa National Park"]->.ourArea;
 (
  way(area.ourArea)["natural"="bare_rock"];
  >;
diff --git a/tutorial/24-mapToArea.osm b/tutorial/24-mapToArea.osm
index 6348dfa..f1c3552 100644
--- a/tutorial/24-mapToArea.osm
+++ b/tutorial/24-mapToArea.osm
@@ -16,7 +16,7 @@ that is found just east of Uluṟu. This is stored in a temporary named set.
 We then use the `map_to_area` statement to find the area corresponding to
 that relation. This is saved in a variable called `mutitjulu`.
 
-We then do a couple of type agnostic queries to find node, ways and relations
+We then do a couple of type agnostic queries to find nodes, ways and relations
 that are tagged as buildings or leisure areas.
 
 @title 24 - Find the area derived from a feature