diff --git a/crate/guides/about.md b/crate/guides/about.md
index 62e41b9..7e8322d 100644
--- a/crate/guides/about.md
+++ b/crate/guides/about.md
@@ -20,7 +20,7 @@ a visual layout with minimal repetition. The macros used are thin wrappers
 for constructors, and don't conceal much.
 
 Specifically, the element-creation macros
-allow for accepting a variable number and order of parameters, and the attrs/style marcros are
+allow for accepting a variable number and order of parameters, and the attrs/style macros are
 essentially HashMap literals, with wrappers that let element macros know how to distinguish
 them.
 
@@ -63,7 +63,7 @@ this framework will in most cases be easier, and require less config and setup o
 with JS frameworks. You may appreciate Rust's compile-time error-checking, and built-in testing.
 
 You may choose this approach over Elm if you're already comfortable with Rust,
-or don't want to code business logic in a purely-functional langauge.
+or don't want to code business logic in a purely-functional language.
 
 Compared with React, you may appreciate the consistency of how to write apps:
 There's no distinction between logic and display code; no restrictions on comments;
diff --git a/crate/guides/fetch.md b/crate/guides/fetch.md
index 5d24b74..ff69b32 100644
--- a/crate/guides/fetch.md
+++ b/crate/guides/fetch.md
@@ -77,7 +77,7 @@ pub fn render() {
 On page load, we trigger an update in the `init` function using `Msg::FetchData`, 
 which points the `update` via `orders.perform_cmd` and a function we've created
 called `fetch_data`. This allows state to be
-update asynchronosly, when the request is complete. `skip()` is a convenience method that
+update asynchronously, when the request is complete. `skip()` is a convenience method that
 sets `Update::ShouldRender` to `Skip`; sending the request doesn't trigger a render.
 We pattern-match the response in the `update` function's`DataFetched` arm: If successful, we update the model.
 If not, we display an error in the console using the `error!` macro.
diff --git a/crate/guides/server_integration.md b/crate/guides/server_integration.md
index 60418cc..5aad4d1 100644
--- a/crate/guides/server_integration.md
+++ b/crate/guides/server_integration.md
@@ -6,7 +6,7 @@ server and frontend using a layout like that in the
 
 A key advantage of this approach is that you can reuse data structures, and code that
 operates on them on both client and server. We use `Serde` to elegantly, and mostly transparently,
- handle [de]serialization. For example, we can use use the same struct which represents a 
+ handle [de]serialization. For example, we can use the same struct which represents a 
 database model on a server in Seed, without redefining or changing it. This includes
 keeping the same methods on both server and client.
 
@@ -65,7 +65,7 @@ shared = { path = "../shared" }
 The client's `cargo.toml` is a standard Seed one. The shared `Cargo.toml` includes
 whatever you need for your shared data structures and code; it will usually include
 `serde` for serializing and deserializing, and may include database code, since
-this crate is a good place for databse models and schema.
+this crate is a good place for database models and schema.
 ```toml
 [package]
 name = "shared"