diff --git a/configuration/auth/custom.mdx b/configuration/auth/custom.mdx
index e8a199086..a84c2dc2b 100644
--- a/configuration/auth/custom.mdx
+++ b/configuration/auth/custom.mdx
@@ -184,7 +184,7 @@ echo -n "your-value-here" | base64 -w 0 | tr '+/' '-_' | tr -d '='
### Generate New JWTs Using the KID and Shared Secret
-Using your newly-created shared secret, you can generate JWT tokens [in your backend](/configuration/app-backend/setup) using the same KID you set in the PowerSync Service configuration. Here's a example TypeScript function using the [`jose`](https://github.com/panva/jose) library:
+Using your newly-created shared secret, you can generate JWT tokens [in your backend](/configuration/app-backend/setup) using the same KID you set in the PowerSync Service configuration. Here's an example TypeScript function using the [`jose`](https://github.com/panva/jose) library:
```typescript
import * as jose from 'jose';
diff --git a/handling-writes/handling-update-conflicts.mdx b/handling-writes/handling-update-conflicts.mdx
index 77176d9f9..065a4f1a9 100644
--- a/handling-writes/handling-update-conflicts.mdx
+++ b/handling-writes/handling-update-conflicts.mdx
@@ -3,7 +3,7 @@ title: "Handling Update Conflicts"
description: "Understand what happens when multiple users update the same records while offline."
---
-By design PowerSync is unopinionated when it comes to handling conflicts on the backend. On the client, mutations are stored in an "upload queue" - an ordered log of mutations. This upload queue must be sequentially drained against backend API endpoints configured by the developer. The developer's app backend therefore dictates how mutations from clients are processed and applied against the source database. PowerSync then replicates and syncs those mutations back to the client. This is known as server-authoritative reconcilliation.
+By design PowerSync is unopinionated when it comes to handling conflicts on the backend. On the client, mutations are stored in an "upload queue" - an ordered log of mutations. This upload queue must be sequentially drained against backend API endpoints configured by the developer. The developer's app backend therefore dictates how mutations from clients are processed and applied against the source database. PowerSync then replicates and syncs those mutations back to the client. This is known as server-authoritative reconciliation.
In the simplest backend implementation, the behavior of the overall system will be per-field Last-Write-Wins (LWW). However, this can be [customized](/handling-writes/custom-conflict-resolution).
diff --git a/integrations/flutterflow/attachments.mdx b/integrations/flutterflow/attachments.mdx
index 09b00df20..b686df275 100644
--- a/integrations/flutterflow/attachments.mdx
+++ b/integrations/flutterflow/attachments.mdx
@@ -73,7 +73,7 @@ The schema of the local SQLite database should now be updated to include the new
## Create `setUpAttachments` Custom Action
-This creates an attachment queue which is responsible for tracking, storing and synching attachment metadata and CRUD operations.
+This creates an attachment queue which is responsible for tracking, storing and syncing attachment metadata and CRUD operations.
1. Navigate to **"Custom Code"** and add a Custom Action.
2. Name the action `setUpAttachments`.
diff --git a/maintenance-ops/monitoring-and-alerting.mdx b/maintenance-ops/monitoring-and-alerting.mdx
index 4d7726602..091b19f31 100644
--- a/maintenance-ops/monitoring-and-alerting.mdx
+++ b/maintenance-ops/monitoring-and-alerting.mdx
@@ -141,7 +141,7 @@ Quote values that contain spaces:
close_reason:"client closing stream"
```
-The following aliases are supported for Sync & API logs. For most properties the alias matches the canonical property name; `error` and `lag` keep a short form because their underlying paths are awkward to type. You can also type the short aliases shown in parentheses; they are normalised to the canonical name on submit.
+The following aliases are supported for Sync & API logs. For most properties the alias matches the canonical property name; `error` and `lag` keep a short form because their underlying paths are awkward to type. You can also type the short aliases shown in parentheses; they are normalized to the canonical name on submit.
| Alias | Property | Description |
| --- | --- | --- |
diff --git a/resources/faq.mdx b/resources/faq.mdx
index 5ec651799..93265a5eb 100644
--- a/resources/faq.mdx
+++ b/resources/faq.mdx
@@ -41,7 +41,7 @@ description: "Frequently asked questions about PowerSync."
_For example, a new record should not be displayed until the server received it, or it should be displayed as pending, or the entire screen must block with a spinner._
- **While PowerSync does not have out-of-the-box support for this due to the great variety of requirements, this is easy to build on top of the sync system.** A simple approach is to store a "status" or "pending changes" column on the table, and set that whenever the client makes a change. When the server receives the change, it then sets it to "processed" / "no pending changes". So when the server has processed the change, the client automatically syncs that status back.For more granular information, record individual changes in a separate table, as explained in [Custom Conflict Resolution](/handling-writes/custom-conflict-resolution).Note: Blocking the entire screen with a spinner is not recommended, since the change may take a very long time to be processed if the user is offline.
+ **While PowerSync does not have out-of-the-box support for this due to the great variety of requirements, this is easy to build on top of the sync system.** A simple approach is to store a "status" or "pending changes" column on the table, and set that whenever the client makes a change. When the server receives the change, it then sets it to "processed" / "no pending changes". So when the server has processed the change, the client automatically syncs that status back. For more granular information, record individual changes in a separate table, as explained in [Custom Conflict Resolution](/handling-writes/custom-conflict-resolution). Note: Blocking the entire screen with a spinner is not recommended, since the change may take a very long time to be processed if the user is offline.
diff --git a/resources/local-first-software.mdx b/resources/local-first-software.mdx
index bced9461c..8d5622dd7 100644
--- a/resources/local-first-software.mdx
+++ b/resources/local-first-software.mdx
@@ -53,7 +53,7 @@ Here's how applications built using PowerSync can be brought closer to the [7 id
| --- | --- |
| **Fast**: By accessing data locally, the software should be able to respond near-instantaneously to user input | PowerSync inherently provides this: All reads and writes use a local SQLite database, resulting in near-zero latency for accessing data. |
| **Multi-Device**: Data should be synchronized across all of the devices on which a user does their work. | PowerSync automatically syncs data to different user devices. |
-| **Offline**: The user should be able to read and write their data anytime, even while offline. | PowerSync allows for offline usage of applications for arbitrarily long periods of time. Developers can also optionally create apps as [offline-only](/client-sdks/advanced/local-only-usage) and turn on syncing of data when it suits them, including on a per-user basis.When syncing is configured, data is synced to users based on the [Sync Streams](/sync/streams/overview) (or [Sync Rules](/sync/rules/overview)) for offline access. Mutations to data while the user is offline are placed in an upload queue and periodically attempted to be [uploaded](/configuration/app-backend/client-side-integration) when connectivity is available (this is automatically managed by the PowerSync Client SDK). |
+| **Offline**: The user should be able to read and write their data anytime, even while offline. | PowerSync allows for offline usage of applications for arbitrarily long periods of time. Developers can also optionally create apps as [offline-only](/client-sdks/advanced/local-only-usage) and turn on syncing of data when it suits them, including on a per-user basis. When syncing is configured, data is synced to users based on the [Sync Streams](/sync/streams/overview) (or [Sync Rules](/sync/rules/overview)) for offline access. Mutations to data while the user is offline are placed in an upload queue and periodically attempted to be [uploaded](/configuration/app-backend/client-side-integration) when connectivity is available (this is automatically managed by the PowerSync Client SDK). |
| **Collaboration**: The ideal is to support real-time collaboration that is on par with the best cloud apps today. | PowerSync allows building collaborative applications either with [custom conflict resolution](/handling-writes/custom-conflict-resolution), or [using CRDT](/client-sdks/advanced/crdts) data structures stored as blob data for fine-grained collaboration. |
| **Longevity**: Work the user did with the software should continue to be accessible indefinitely, even after the company that produced the software is gone. | PowerSync relies on open-source and source-available software, meaning that the end-user can self-host Postgres (open-source) and the [PowerSync Service](/architecture/powersync-service) (source-available) should they wish to continue using PowerSync to sync data after the software producer shuts down backend services. There is also an onus on the software developer to ensure longevity, such as allowing exporting of data and avoiding reliance on other proprietary backend services. |
| **Privacy**: The software should use end-to-end encryption so that servers that store a copy of users’ files only hold encrypted data that they cannot read. | For details on end-to-end encryption with PowerSync, refer to our [Encryption](/client-sdks/advanced/data-encryption) section. |
diff --git a/resources/supported-platforms.mdx b/resources/supported-platforms.mdx
index e0c800f40..912e688e5 100644
--- a/resources/supported-platforms.mdx
+++ b/resources/supported-platforms.mdx
@@ -184,7 +184,7 @@ PowerSync supports a wide number of target platforms across its many SDKs. We ai
In general, PowerSync aims to support any platform version that still receives security updates from the platform provider. For platforms that follow an LTS and Current release model, this means we aim to support all active LTS releases along with the Current release.
-Supporting every version that fits the above criteria is [not always feasible](#exceptions). When we cannot support all of them, we prioritise support for newer versions over older versions to ease maintenance. We will occasionally maintain support for an older version on a case-by-case basis for larger customers. Reach out to us at `hello@powersync.com` if this is you.
+Supporting every version that fits the above criteria is [not always feasible](#exceptions). When we cannot support all of them, we prioritize support for newer versions over older versions to ease maintenance. We will occasionally maintain support for an older version on a case-by-case basis for larger customers. Reach out to us at `hello@powersync.com` if this is you.
### Exceptions