diff --git a/beta/src/content/learn/extracting-state-logic-into-a-reducer.md b/beta/src/content/learn/extracting-state-logic-into-a-reducer.md
index a2152909..b389d6f3 100644
--- a/beta/src/content/learn/extracting-state-logic-into-a-reducer.md
+++ b/beta/src/content/learn/extracting-state-logic-into-a-reducer.md
@@ -1794,7 +1794,7 @@ textarea {
 
 </Sandpack>
 
-This works and clears the input when you hit "Send."
+This works and clears the input when you hit "Send".
 
 However, *from the user's perspective*, sending a message is a different action than editing the field. To reflect that, you could instead create a *new* action called `sent_message`, and handle it separately in the reducer:
 
diff --git a/beta/src/content/learn/reacting-to-input-with-state.md b/beta/src/content/learn/reacting-to-input-with-state.md
index eff2e9d3..10c728eb 100644
--- a/beta/src/content/learn/reacting-to-input-with-state.md
+++ b/beta/src/content/learn/reacting-to-input-with-state.md
@@ -305,7 +305,7 @@ body { margin: 0; }
 
 </Sandpack>
 
-Pages like this are often called "living styleguides" or "storybooks."
+Pages like this are often called "living styleguides" or "storybooks".
 
 </DeepDive>
 
diff --git a/beta/src/content/learn/removing-effect-dependencies.md b/beta/src/content/learn/removing-effect-dependencies.md
index c167009f..78608c54 100644
--- a/beta/src/content/learn/removing-effect-dependencies.md
+++ b/beta/src/content/learn/removing-effect-dependencies.md
@@ -344,7 +344,7 @@ button { margin: 10px; }
 
 </Sandpack>
 
-Let's say that you wanted to run the Effect "only on mount." You've read that [empty (`[]`) dependencies](/learn/lifecycle-of-reactive-effects#what-an-effect-with-empty-dependencies-means) do that, so you've decided to ignore the linter, and forcefully specified `[]` as the dependencies.
+Let's say that you wanted to run the Effect "only on mount". You've read that [empty (`[]`) dependencies](/learn/lifecycle-of-reactive-effects#what-an-effect-with-empty-dependencies-means) do that, so you've decided to ignore the linter, and forcefully specified `[]` as the dependencies.
 
 This counter was supposed to increment every second by the amount configurable with the two buttons. However, since you "lied" to React that this Effect doesn't depend on anything, React forever keeps using the `onTick` function from the initial render. [During that render,](/learn/state-as-a-snapshot#rendering-takes-a-snapshot-in-time) `count` was `0` and `increment` was `1`. This is why `onTick` from that render always calls `setCount(0 + 1)` every second, and you always see `1`. Bugs like this are harder to fix when they're spread across multiple components.
 
diff --git a/beta/src/content/learn/synchronizing-with-effects.md b/beta/src/content/learn/synchronizing-with-effects.md
index 31de4b8d..9177d735 100644
--- a/beta/src/content/learn/synchronizing-with-effects.md
+++ b/beta/src/content/learn/synchronizing-with-effects.md
@@ -1125,7 +1125,7 @@ body {
 
 This form renders two `<MyInput />` components.
 
-Press "Show form" and notice that the second field automatically gets focused. This is because both of the `<MyInput />` components try to focus the field inside. When you call `focus()` for two input fields in a row, the last one always "wins."
+Press "Show form" and notice that the second field automatically gets focused. This is because both of the `<MyInput />` components try to focus the field inside. When you call `focus()` for two input fields in a row, the last one always "wins".
 
 Let's say you want to focus the first field. The first `MyInput` component now receives a boolean `shouldFocus` prop set to `true`. Change the logic so that `focus()` is only called if the `shouldFocus` prop received by `MyInput` is `true`.
 
diff --git a/beta/src/content/learn/updating-objects-in-state.md b/beta/src/content/learn/updating-objects-in-state.md
index b1c1b5c4..909f0e33 100644
--- a/beta/src/content/learn/updating-objects-in-state.md
+++ b/beta/src/content/learn/updating-objects-in-state.md
@@ -800,7 +800,7 @@ In practice, you can often "get away" with mutating state in React, but we stron
 <Recap>
 
 * Treat all state in React as immutable.
-* When you store objects in state, mutating them will not trigger renders and will change the state in previous render "snapshots."
+* When you store objects in state, mutating them will not trigger renders and will change the state in previous render "snapshots".
 * Instead of mutating an object, create a *new* version of it, and trigger a re-render by setting state to it.
 * You can use the `{...obj, something: 'newValue'}` object spread syntax to create copies of objects.
 * Spread syntax is shallow: it only copies one level deep.