Out of the box --> out-of-the-box (#1665)

docs/authentication/configuration/email-sms-templates.mdx

@@ -60,7 +60,7 @@ The following operations are available for an email template:
 
 The following settings can be changed per email template:
 
-- **Delivered by Clerk**: out of the box, Clerk will deliver your emails using its own Email Service Provider (ESP), which is currently [SendGrid](https://sendgrid.com/). However, if you wish to handle delivery of emails on your own, then you can toggle this setting off. This means that Clerk will no longer be sending this particular email and in order to deliver it yourself, you will need to listen to the `emails.created` [webhook](/docs/integrations/webhooks/overview) and extract the necessary info from the event payload.
+- **Delivered by Clerk**: Clerk will deliver your emails using its own Email Service Provider (ESP), which is currently [SendGrid](https://sendgrid.com/). However, if you wish to handle delivery of emails on your own, then you can toggle this setting off. This means that Clerk will no longer be sending this particular email and in order to deliver it yourself, you will need to listen to the `emails.created` [webhook](/docs/integrations/webhooks/overview) and extract the necessary info from the event payload.
 - **Name**: a name for the template on the template listing page. It does not affect the outgoing email in any way.
 - **From**: the email address that will be used as the **From** address in the email header. The format is `<local part>@<your-domain>`. You can change the local part to a custom value. If no value is provided, it defaults `noreply`.
 - **Reply-To**: the email address that will be used as the **Reply-To** address in the email header. This is useful if you want to direct replies to a different email address than the one used in the **From** field. The format is `<local part>@<your-domain>`. You can change the local part to a custom value. If no value is provided, the **Reply-To** header will be omitted.
@@ -111,7 +111,7 @@ To access the SMS templates:
 
 ### Delivered by Clerk
 
-Out of the box, Clerk will deliver your SMS messages using its own SMS Gateway. However, if you wish to handle SMS delivery on your own, then you can toggle **Delivered by Clerk** off.
+Clerk will deliver your SMS messages using its own SMS Gateway. However, if you wish to handle SMS delivery on your own, then you can toggle **Delivered by Clerk** off.
 
 This means that Clerk will no longer be sending this particular SMS and in order to deliver it yourself, you will need to listen to the `sms.created` [webhook](/docs/integrations/webhooks/overview) and extract the necessary info from the event payload.
 

docs/authentication/configuration/sign-up-sign-in-options.mdx

@@ -41,7 +41,7 @@ Authentication strategies are methods that users can use to sign up and sign in
 
 Clerk offers two kinds of authentication strategies: **password** and **passwordless**.
 
-Choosing the **password** strategy requires users to set a password during the sign up process. Clerk offers out-of-the-box protection against weak and compromised passwords and the only requirement enforced is that the password be a miminum of 8 characters.
+Choosing the **password** strategy requires users to set a password during the sign up process. Passwords are required to be at least 8 characters long, and Clerk offers out-of-the-box protection against weak and compromised passwords.
 
 > [!NOTE]
 > Passwordless authentication remains available to users, even if the password strategy is enabled.

docs/authentication/saml/jit-provisioning.mdx

@@ -7,7 +7,7 @@ Just-in-Time (JIT) Provisioning, or automatic account provisioning, is a process
 
 Using JIT Provisioning means your IT department won't have to manually create user accounts for each of the services or apps your employees use to get work done.
 
-Clerk supports JIT account provisioning for all [supported SAML providers](/docs/authentication/saml/overview) out of the box.
+Clerk supports JIT account provisioning for all [supported SAML providers](/docs/authentication/saml/overview).
 
 Check your preferred SAML provider's documentation to enable JIT account provisioning on their side.
 

docs/components/organization/organization-profile.mdx

@@ -7,7 +7,7 @@ description: Clerks <OrganizationProfile /> component is used to render a beauti
 
 The `<OrganizationProfile />` component is used to render a beautiful, full-featured organization management UI that allows users to manage their organization profile and security settings.
 
-Out of the box, this component's **General** tab displays the organization's information and the **Leave organization** button. Admins will be able to see the **Update profile** button, **Verified domains** section, and **Delete organization** button.
+This component's **General** tab displays the organization's information and the **Leave organization** button. Admins will be able to see the **Update profile** button, **Verified domains** section, and **Delete organization** button.
 
 The **Members** tab shows the organization's members along with their join dates and roles. Admins will have the ability to invite a member, change a member's role, or remove them from the organization. Admins will have tabs within the **Members** tab to view the organization's [invitations](/docs/organizations/overview#organization-invitations) and [requests](/docs/organizations/overview#membership-requests).
 

docs/components/organization/organization-switcher.mdx

@@ -7,7 +7,7 @@ description: Clerk's <OrganizationSwitcher /> component is used to enable the ab
 
 The `<OrganizationSwitcher />` component allows a user to switch between their account types - their personal account and their joined organizations. This component is useful for applications that have a multi-tenant architecture, where users can be part of multiple organizations.
 
-Out of the box, this component will show notifications to the user if they have organization [invitations](/docs/organizations/overview#organization-invitations) or [suggestions](/docs/organizations/overview#suggestions). Admins will be able to see notifications for [requests](/docs/organizations/overview#membership-requests) to join an organization.
+This component will show notifications to the user if they have organization [invitations](/docs/organizations/overview#organization-invitations) or [suggestions](/docs/organizations/overview#suggestions). Admins will be able to see notifications for [requests](/docs/organizations/overview#membership-requests) to join an organization.
 
 If you would like to learn how to hide a user's personal account in order to enforce an organization-centric application, see the [dedicated guide.](/docs/guides/force-organizations)
 

docs/deployments/migrate-overview.mdx

@@ -29,7 +29,7 @@ Consider that any export of your data will be a snapshot in time. This means tha
 
 #### Active sessions / session management
 
-Another consideration is centered around how you handle session management. While most authentication providers don't provide session management out of the box, Clerk does. This means that when you switch over to using Clerk you'll be changing the system that handles your users' active sessions. This will likely end any currently active sessions initiated by your previous session management service (unless you are able to gracefully handle this somehow within your architecture).
+Another consideration is centered around how you handle session management. While most authentication providers don't provide session management out-of-the-box, Clerk does. This means that when you switch over to using Clerk you'll be changing the system that handles your users' active sessions. This will likely end any currently active sessions initiated by your previous session management service (unless you are able to gracefully handle this somehow within your architecture).
 
 #### Foreign keys
 

docs/guides/architecture-scenarios.mdx

@@ -13,7 +13,7 @@ We will share some of the common characteristics of apps in each scenario as wel
 
 ## B2C: Business to Consumer
 
-B2C companies focus on selling products or services directly to consumers. Some popular examples are Netflix, Headspace, and Spotify. Clerk supports the B2C user management model out of the box, with little-to-no configuration.
+B2C companies focus on selling products or services directly to consumers. Some popular examples are Netflix, Headspace, and Spotify. Clerk supports the B2C user management model out-of-the-box, with little-to-no configuration.
 
 In a B2C scenario, applications generally share the following characteristics:
 

docs/guides/routing.mdx

@@ -23,7 +23,7 @@ There are three routing strategies that can be passed:
 - [`hash`](#hash-routing)
 - [`virtual`](#virtual-routing)
 
-Out of the box, Clerk will attempt to select the routing strategy that best integrates with your framework of choice. If for some reason the default routing strategy doesn't work for you, use the information below to pick a strategy that will work for your setup.
+Clerk will attempt to select the routing strategy that best integrates with your framework of choice. If for some reason the default routing strategy doesn't work for you, use the information below to pick a strategy that will work for your setup.
 
 ### `path` routing