diff --git a/ghdocs/BestPractices/ComponentDesign.md b/ghdocs/BestPractices/ComponentDesign.md
index 5368c017587def..781b971f8ba24b 100644
--- a/ghdocs/BestPractices/ComponentDesign.md
+++ b/ghdocs/BestPractices/ComponentDesign.md
@@ -83,7 +83,7 @@ controlling the disabled state of the input element.)
 
 |BAD|GOOD|Notes|
 |---|----|-----|
-|isChecked|checked|There is an HTML precidence for checked.|
+|isChecked|checked|There is an HTML precedence for checked.|
 |isVisible|visible|
 |isSelected|selected|
 |isEnabled|disabled|If the state is enabled by default, it should be named for the exceptional case.|
@@ -464,9 +464,9 @@ class Foo extends React.Component {
   }
 ```
 
-## Experimental: Use a store for storing shared state within a component heirachy which must be shared across objects
+## Experimental: Use a store for storing shared state within a component hierarchy which must be shared across objects
 
-While React state management is very useful for simple, private state, it becomes unweildy when many things share that state
+While React state management is very useful for simple, private state, it becomes unwieldy when many things share that state
 and you start ending up with many owners of the same state value. In these cases it may drive you towards a flux solution, but
 before we jump there, lets call out a few things.
 
@@ -571,7 +571,7 @@ html[dir=rtl] .ms-Foo {
 }
 ```
 
-Additionaly try to have symetrical paddings rather than using padding-right or left specifics.
+Additionally try to have symmetrical paddings rather than using padding-right or left specifics.
 
 ## Do not use core fabric classnames, but instead use core fabric scss mixins.
 
diff --git a/ghdocs/BestPractices/Styling.md b/ghdocs/BestPractices/Styling.md
index 9a36550aefe33c..9668e3af9ed3ab 100644
--- a/ghdocs/BestPractices/Styling.md
+++ b/ghdocs/BestPractices/Styling.md
@@ -295,7 +295,7 @@ Scenarios like "make this area of the screen use a different theme" become reall
 
 If a button has 20 different possible states, using scss you must load the css for all 20 of the states pre-emptively, so you end up loading way more rules than you will ever actually use. There is no "plt1 styles vs delay loaded styles". The best you can do is to partition your css to specific modules, and delay load the modules. But in this model, you will still preempt loading a lot of rules that aren't used.
 
-Sass also encourages "mixins" as a way to have one definition of styles that can be used in multiple places. This completely fights against bundle size, since mixins simply stamp duplicates copies of the same rules whereever they're used, resulting in bloated (but highly compressable) style definitions. The compression helps but all of this could be avoided by using a different approach to defining our styling.
+Sass also encourages "mixins" as a way to have one definition of styles that can be used in multiple places. This completely fights against bundle size, since mixins simply stamp duplicates copies of the same rules wherever they're used, resulting in bloated (but highly compressible) style definitions. The compression helps but all of this could be avoided by using a different approach to defining our styling.
 
 ## Constant battle with specificity
 
diff --git a/ghdocs/Contributing/ChangeFiles.md b/ghdocs/Contributing/ChangeFiles.md
index 887a1d8b608415..77a3e3cf7d0aa3 100644
--- a/ghdocs/Contributing/ChangeFiles.md
+++ b/ghdocs/Contributing/ChangeFiles.md
@@ -5,7 +5,7 @@ When we publish new releases, we need to know what major, minor or patch changes
 
 ## Writing a change description
 
-Please write a change desription such that it is easy for the release manager to understand the impact of the change. When we ship out new releases, we need to build a cumulative set of **Release notes**. Those release notes are a summation of individual changes checked in. Hence, it is important that developers write clear and understandable change descriptions.
+Please write a change description such that it is easy for the release manager to understand the impact of the change. When we ship out new releases, we need to build a cumulative set of **Release notes**. Those release notes are a summation of individual changes checked in. Hence, it is important that developers write clear and understandable change descriptions.
 
 ## Change annotation