diff --git a/docs/source/embedding.md b/docs/source/embedding.md
index f7e9d5c717..7685f547f7 100644
--- a/docs/source/embedding.md
+++ b/docs/source/embedding.md
@@ -51,7 +51,7 @@ This HTML snippet is composed of multiple `<script>` tags embedded into an HTML
 
 - Then there are a number of script tags, each with mime type
   `application/vnd.jupyter.widget-view+json`, corresponding to the views which
-  you want to display in the web page. These script tags must be in the body of
+  you want to display on the web page. These script tags must be in the body of
   the page, and are replaced with the rendered widgets. The JSON schema for the
   content of these script tags is found in the `@jupyter-widgets/schema` npm
   package.
@@ -73,7 +73,7 @@ the `application/vnd.jupyter.widget-state+json` format specified in the
 
 Embeddable code for the widgets can also be produced from Python. The
 `ipywidgets.embed` module provides several functions for embedding widgets
-into HTML documents programatically.
+into HTML documents programmatically.
 
 Use `embed_minimal_html` to create a simple, stand-alone HTML page:
 
diff --git a/docs/source/examples/Layout Example.ipynb b/docs/source/examples/Layout Example.ipynb
index 225f297c20..7504739b10 100644
--- a/docs/source/examples/Layout Example.ipynb	
+++ b/docs/source/examples/Layout Example.ipynb	
@@ -316,4 +316,4 @@
  },
  "nbformat": 4,
  "nbformat_minor": 2
-}
+}
\ No newline at end of file
diff --git a/docs/source/examples/Layout Templates.ipynb b/docs/source/examples/Layout Templates.ipynb
index 828831e903..38bd59a1a2 100644
--- a/docs/source/examples/Layout Templates.ipynb	
+++ b/docs/source/examples/Layout Templates.ipynb	
@@ -6,7 +6,7 @@
    "source": [
     "# Using Layout Templates\n",
     "\n",
-    "As we showed in [Layout and Styling of Jupyter widgets](Widget%20Styling.ipynb) multiple widgets can be aranged together using the flexible [GridBox](Widget%20Styling.ipynb#The-Grid-Layout) specification. However, use of the specification involves some understanding of CSS properties and may impose sharp learning curve. Here, we will describe layout templates built on top of `GridBox` that simplify creation of common widget layouts."
+    "As we showed in [Layout and Styling of Jupyter widgets](Widget%20Styling.ipynb) multiple widgets can be arranged together using the flexible [GridBox](Widget%20Styling.ipynb#The-Grid-Layout) specification. However, use of the specification involves some understanding of CSS properties and may impose sharp learning curve. Here, we will describe layout templates built on top of `GridBox` that simplify creation of common widget layouts."
    ]
   },
   {
@@ -43,7 +43,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "You can easily create a layout with 4 widgets aranged on 2x2 matrix using the `TwoByTwoLayout` widget: "
+    "You can easily create a layout with 4 widgets arranged on 2x2 matrix using the `TwoByTwoLayout` widget: "
    ]
   },
   {
@@ -536,7 +536,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "In this examples, we will demonstrate how to use `GridspecLayout` and `bqplot` widget to create a multipanel scatter plot. To run this example you will need to install the [bqplot](https://bqplot.readthedocs.io/en/latest/) package."
+    "In these examples, we will demonstrate how to use `GridspecLayout` and `bqplot` widget to create a multipanel scatter plot. To run this example you will need to install the [bqplot](https://bqplot.readthedocs.io/en/latest/) package."
    ]
   },
   {
@@ -715,4 +715,4 @@
  },
  "nbformat": 4,
  "nbformat_minor": 4
-}
+}
\ No newline at end of file
diff --git a/docs/source/examples/Widget Low Level.ipynb b/docs/source/examples/Widget Low Level.ipynb
index adde0c7aad..23e623a78e 100644
--- a/docs/source/examples/Widget Low Level.ipynb	
+++ b/docs/source/examples/Widget Low Level.ipynb	
@@ -49,7 +49,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Jupyter interactive widgets are interactive elements, think sliders, textboxes, buttons, that have representations both in the kernel (place where code is executed) and the front-end (the Notebook web interface).  To do this, a clean, well abstracted communication layer must exist."
+    "Jupyter interactive widgets are interactive elements, think sliders, text boxes, buttons, that have representations both in the kernel (place where code is executed) and the front-end (the Notebook web interface).  To do this, a clean, well-abstracted communication layer must exist."
    ]
   },
   {
@@ -92,7 +92,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Using comms, the widget base layer is designed to keep state in sync.  In the kernel, a Widget instance exists.  This Widget instance has a corresponding WidgetModel instance in the front-end.  The Widget and WidgetModel store the same state.  The widget framework ensures both models are kept in sync with eachother.  If the WidgetModel is changed in the front-end, the Widget receives the same change in the kernel.  Vise versa, if the Widget in the kernel is changed, the WidgetModel in the front-end receives the same change.  There is no single source of truth, both models have the same precedence.  Although a notebook has the notion of cells, neither Widget or WidgetModel are bound to any single cell."
+    "Using comms, the widget base layer is designed to keep state in sync.  In the kernel, a Widget instance exists.  This Widget instance has a corresponding WidgetModel instance in the front-end.  The Widget and WidgetModel store the same state.  The widget framework ensures both models are kept in sync with each other.  If the WidgetModel is changed in the front-end, the Widget receives the same change in the kernel.  Vice versa, if the Widget in the kernel is changed, the WidgetModel in the front-end receives the same change.  There is no single source of truth, both models have the same precedence.  Although a notebook has the notion of cells, neither Widget or WidgetModel are bound to any single cell."
    ]
   },
   {
@@ -233,7 +233,7 @@
     }
    },
    "source": [
-    "The WidgetModel class is specified by module and name.  Require.js is then used to asynchronously load the WidgetModel class. The message triggers a comm to be created in the front-end with same GUID as the back-end.  Then, the new comm gets passed into the WidgetManager in the front-end, which creates an instance of the WidgetModel class, linked to the comm.  Both the Widget and WidgetModel repurpose the comm GUID as their own."
+    "The WidgetModel class is specified by module and name.  Require.js is then used to asynchronously load the WidgetModel class. The message triggers a comm to be created in the front-end with the same GUID as the back-end.  Then, the new comm gets passed into the WidgetManager in the front-end, which creates an instance of the WidgetModel class, linked to the comm.  Both the Widget and WidgetModel repurpose the comm GUID as their own."
    ]
   },
   {
@@ -251,7 +251,7 @@
     }
    },
    "source": [
-    "Asynchronously, the kernel sends an initial state push, containing all of the initial state of the Widget, to the front-end, immediately after the comm-open message.  This state message may or may not be received by the time the WidgetModel is constructed.  Regardless, the message is cached and gets processed once the WidgetModel has been constructed.  The initial state push is what causes the WidgetModel in the front-end to become in sync with the Widget in the kernel."
+    "Asynchronously, the kernel sends an initial state push, containing the initial state of the Widget, to the front-end, immediately after the comm-open message.  This state message may or may not be received by the time the WidgetModel is constructed.  Regardless, the message is cached and gets processed once the WidgetModel has been constructed.  The initial state push is what causes the WidgetModel in the front-end to become in sync with the Widget in the kernel."
    ]
   },
   {
@@ -407,7 +407,7 @@
     "\n",
     "### Custom serialization and de-serialization on the Python side\n",
     "\n",
-    "In many cases, a custom serialization must be specified for trait attributes. For example\n",
+    "In many cases, a custom serialization must be specified for trait attributes. For example,\n",
     "\n",
     " - if the trait attribute is not json serializable\n",
     " - if the trait attribute contains data that is not needed by the JavaScript side.\n",
@@ -429,7 +429,7 @@
     "\n",
     "where `datetime_to_json(value, widget)` and `datetime_from_json(value, widget)` return or handle json data-structures that are amenable to the front-end.\n",
     "\n",
-    "**The case of parent child relationships between widget models**\n",
+    "**The case of parent-child relationships between widget models**\n",
     "\n",
     "When a widget model holds other widget models, you must use the serializers and deserializers provided in ipywidgets packed into the `widget_serialization` dictionary.\n",
     "\n",
@@ -480,7 +480,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Because the API of any given widget **must exist in the kernel**, the kernel is the natural place for widgets to be installed.  However, **kernels, as of now, don’t host static assets**.  Instead, static assets are hosted by the webserver, which is the entity that sits between the kernel and the front-end.  This is a problem, because it means widgets have components that need to be **installed both in the webserver and the kernel**.  The kernel components are easy to install, because you can rely on the language’s built in tools.  The static assets for the webserver complicate things, because an extra step is required to let the webserver know where the assets are."
+    "Because the API of any given widget **must exist in the kernel**, the kernel is the natural place for widgets to be installed.  However, **kernels, as of now, don’t host static assets**.  Instead, static assets are hosted by the webserver, which is the entity that sits between the kernel and the front-end.  This is a problem because it means widgets have components that need to be **installed both in the webserver and the kernel**.  The kernel components are easy to install, because you can rely on the language’s built-in tools.  The static assets for the webserver complicate things, because an extra step is required to let the webserver know where the assets are."
    ]
   },
   {
@@ -498,7 +498,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "In the case of the classic Jupyter notebook, static assets are made available to the Jupyter notebook in the form of a Jupyter extensions. JavaScript bundles are copied in a directory accessible through the `nbextensions/` handler.  Nbextensions also have a mechanism for running your code on page load.  This can be set using the install-nbextension command."
+    "In the case of the classic Jupyter notebook, static assets are made available to the Jupyter notebook in the form of a Jupyter extension. JavaScript bundles are copied in a directory accessible through the `nbextensions/` handler.  Nbextensions also have a mechanism for running your code on page load.  This can be set using the install-nbextension command."
    ]
   },
   {
@@ -548,4 +548,4 @@
  },
  "nbformat": 4,
  "nbformat_minor": 2
-}
+}
\ No newline at end of file