diff --git a/book/src/programmability/dynamic-object-fields.md b/book/src/programmability/dynamic-object-fields.md
index 4b58f45..5407a2f 100644
--- a/book/src/programmability/dynamic-object-fields.md
+++ b/book/src/programmability/dynamic-object-fields.md
@@ -80,7 +80,7 @@ wrapped_ into a separate object.
 
 ## Pricing Differences
 
-Dynamic Object Fields come a little more exensive than dynamic fields. Because of their internal
+Dynamic Object Fields come a little more expensive than dynamic fields. Because of their internal
 structure, they require 2 objects: the Wrapper for Name and the Value. Because of this, the cost of
 adding and accessing object fields (loading 2 objects compared to 1 for dynamic fields) is higher.
 
diff --git a/reference/src/functions.md b/reference/src/functions.md
index 1a40003..21be19c 100644
--- a/reference/src/functions.md
+++ b/reference/src/functions.md
@@ -105,7 +105,7 @@ In addition to `public` functions, you might have some functions in your modules
 use as the entry point to execution. The `entry` modifier is designed to allow module functions to
 initiate execution, without having to expose the functionality to other modules.
 
-Essentially, the combination of `pbulic` and `entry` functions define the "main" functions of a
+Essentially, the combination of `public` and `entry` functions define the "main" functions of a
 module, and they specify where Move programs can start executing.
 
 Keep in mind though, an `entry` function _can_ still be called by other Move functions. So while