diff --git a/aspnetcore/blazor/forms-and-input-components.md b/aspnetcore/blazor/forms-and-input-components.md
index f697847a5ca4..637afb5ec52a 100644
--- a/aspnetcore/blazor/forms-and-input-components.md
+++ b/aspnetcore/blazor/forms-and-input-components.md
@@ -85,7 +85,7 @@ A form is defined using the Blazor framework's <xref:Microsoft.AspNetCore.Compon
 @inject ILogger<FormExample1> Logger
 
 <EditForm Model="@exampleModel" OnSubmit="@HandleSubmit">
-    <InputText id="name" @bind-Value="exampleModel.Name" />
+    <InputText @bind-Value="exampleModel.Name" />
 
     <button type="submit">Submit</button>
 </EditForm>
@@ -106,7 +106,7 @@ In the preceding `FormExample1` component:
 
 * The <xref:Microsoft.AspNetCore.Components.Forms.EditForm> component is rendered where the `<EditForm>` element appears.
 * The model is created in the component's `@code` block and held in a private field (`exampleModel`). The field is assigned to  <xref:Microsoft.AspNetCore.Components.Forms.EditForm.Model?displayProperty=nameWithType>'s attribute (`Model`) of the `<EditForm>` element.
-* The <xref:Microsoft.AspNetCore.Components.Forms.InputText> component (`id="name"`) is an input component for editing string values. The `@bind-Value` directive attribute binds the `exampleModel.Name` model property to the <xref:Microsoft.AspNetCore.Components.Forms.InputText> component's <xref:Microsoft.AspNetCore.Components.Forms.InputBase%601.Value%2A> property.
+* The <xref:Microsoft.AspNetCore.Components.Forms.InputText> component is an input component for editing string values. The `@bind-Value` directive attribute binds the `exampleModel.Name` model property to the <xref:Microsoft.AspNetCore.Components.Forms.InputText> component's <xref:Microsoft.AspNetCore.Components.Forms.InputBase%601.Value%2A> property.
 * The `HandleSubmit` method is registered as a handler for the <xref:Microsoft.AspNetCore.Components.Forms.EditForm.OnSubmit> callback. The handler is called when the form is submitted by the user.
 
 To demonstrate how the preceding <xref:Microsoft.AspNetCore.Components.Forms.EditForm> component works with [data annotations](xref:mvc/models/validation) validation:
@@ -159,7 +159,7 @@ In the preceding `FormExample1` component:
 
 * The <xref:Microsoft.AspNetCore.Components.Forms.EditForm> component is rendered where the `<EditForm>` element appears.
 * The model is created in the component's `@code` block and held in a private field (`exampleModel`). The field is assigned to  <xref:Microsoft.AspNetCore.Components.Forms.EditForm.Model?displayProperty=nameWithType>'s attribute (`Model`) of the `<EditForm>` element.
-* The <xref:Microsoft.AspNetCore.Components.Forms.InputText> component (`id="name"`) is an input component for editing string values. The `@bind-Value` directive attribute binds the `exampleModel.Name` model property to the <xref:Microsoft.AspNetCore.Components.Forms.InputText> component's <xref:Microsoft.AspNetCore.Components.Forms.InputBase%601.Value%2A> property.
+* The <xref:Microsoft.AspNetCore.Components.Forms.InputText> component is an input component for editing string values. The `@bind-Value` directive attribute binds the `exampleModel.Name` model property to the <xref:Microsoft.AspNetCore.Components.Forms.InputText> component's <xref:Microsoft.AspNetCore.Components.Forms.InputBase%601.Value%2A> property.
 * The `HandleValidSubmit` method is assigned to <xref:Microsoft.AspNetCore.Components.Forms.EditForm.OnValidSubmit>. The handler is called if the form passes validation.
 * The data annotations validator (<xref:Microsoft.AspNetCore.Components.Forms.DataAnnotationsValidator> component&dagger;) attaches validation support using data annotations:
   * If the `<input>` form field is left blank when the **`Submit`** button is selected, an error appears in the validation summary (<xref:Microsoft.AspNetCore.Components.Forms.ValidationSummary> component&Dagger;) ("`The Name field is required.`") and `HandleValidSubmit` is **not** called.
@@ -1795,12 +1795,20 @@ Set the `CustomFieldClassProvider` class as the Field CSS Class Provider on the
 
 :::code language="razor" source="~/../blazor-samples/7.0/BlazorSample_WebAssembly/Pages/forms-and-validation/FormExample8.razor" highlight="21":::
 
-The preceding example checks the validity of all form fields and applies a style to each field. If the form should only apply custom styles to a subset of the fields, make `CustomFieldClassProvider` apply styles conditionally. The following `CustomFieldClassProvider2` example only applies a style to the `Name` field. For any fields with names not matching `Name`, `string.Empty` is returned, and no style is applied.
+The preceding example checks the validity of all form fields and applies a style to each field. If the form should only apply custom styles to a subset of the fields, make `CustomFieldClassProvider` apply styles conditionally. The following `CustomFieldClassProvider2` example only applies a style to the `Name` field. For any fields with names not matching `Name`, `string.Empty` is returned, and no style is applied. Using reflection, the field is matched to the model member's property or field name, not an `id` assigned to the HTML entity.
 
 `CustomFieldClassProvider2.cs`:
 
 :::code language="csharp" source="~/../blazor-samples/7.0/BlazorSample_WebAssembly/CustomFieldClassProvider2.cs":::
 
+> [!NOTE]
+> Matching the field name in the preceding example is case sensitive, so a model property member designated "`Name`" must match a conditional check on "`Name`":
+>
+> * <span aria-hidden="true">✔️</span><span class="visually-hidden">Correctly matches:</span> `fieldIdentifier.FieldName == "Name"`
+> * <span aria-hidden="true">❌</span><span class="visually-hidden">Fails to match:</span> `fieldIdentifier.FieldName == "name"`
+> * <span aria-hidden="true">❌</span><span class="visually-hidden">Fails to match:</span> `fieldIdentifier.FieldName == "NAME"`
+> * <span aria-hidden="true">❌</span><span class="visually-hidden">Fails to match:</span> `fieldIdentifier.FieldName == "nAmE"`
+
 Add an additional property to `ExampleModel`, for example:
 
 ```csharp
@@ -1811,7 +1819,7 @@ public string? Description { get; set; }
 Add the `Description` to the `ExampleForm7` component's form:
 
 ```razor
-<InputText id="description" @bind-Value="exampleModel.Description" />
+<InputText @bind-Value="exampleModel.Description" />
 ```
 
 Update the `EditContext` instance in the component's `OnInitialized` method to use the new Field CSS Class Provider:
@@ -1820,7 +1828,7 @@ Update the `EditContext` instance in the component's `OnInitialized` method to u
 editContext?.SetFieldCssClassProvider(new CustomFieldClassProvider2());
 ```
 
-Because a CSS validation class isn't applied to the `Description` field (`id="description"`), it isn't styled. However, field validation runs normally. If more than 10 characters are provided, the validation summary indicates the error:
+Because a CSS validation class isn't applied to the `Description` field, it isn't styled. However, field validation runs normally. If more than 10 characters are provided, the validation summary indicates the error:
 
 > Description is too long.
 
@@ -1908,7 +1916,7 @@ public string? Description { get; set; }
 Add the `Description` to the `ExampleForm7` component's form:
 
 ```razor
-<InputText id="description" @bind-Value="exampleModel.Description" />
+<InputText @bind-Value="exampleModel.Description" />
 ```
 
 Update the `EditContext` instance in the component's `OnInitialized` method to use the new Field CSS Class Provider:
@@ -1917,7 +1925,7 @@ Update the `EditContext` instance in the component's `OnInitialized` method to u
 editContext?.SetFieldCssClassProvider(new CustomFieldClassProvider2());
 ```
 
-Because a CSS validation class isn't applied to the `Description` field (`id="description"`), it isn't styled. However, field validation runs normally. If more than 10 characters are provided, the validation summary indicates the error:
+Because a CSS validation class isn't applied to the `Description` field, it isn't styled. However, field validation runs normally. If more than 10 characters are provided, the validation summary indicates the error:
 
 > Description is too long.
 
@@ -2005,7 +2013,7 @@ public string Description { get; set; }
 Add the `Description` to the `ExampleForm7` component's form:
 
 ```razor
-<InputText id="description" @bind-Value="exampleModel.Description" />
+<InputText @bind-Value="exampleModel.Description" />
 ```
 
 Update the `EditContext` instance in the component's `OnInitialized` method to use the new Field CSS Class Provider:
@@ -2014,7 +2022,7 @@ Update the `EditContext` instance in the component's `OnInitialized` method to u
 editContext.SetFieldCssClassProvider(new CustomFieldClassProvider2());
 ```
 
-Because a CSS validation class isn't applied to the `Description` field (`id="description"`), it isn't styled. However, field validation runs normally. If more than 10 characters are provided, the validation summary indicates the error:
+Because a CSS validation class isn't applied to the `Description` field, it isn't styled. However, field validation runs normally. If more than 10 characters are provided, the validation summary indicates the error:
 
 > Description is too long.
 
@@ -2229,8 +2237,117 @@ A side effect of the preceding approach is that a validation summary (<xref:Micr
 }
 ```
 
+## Large form payloads and the SignalR message size limit
+
+*This section only applies to Blazor Server apps and hosted Blazor WebAssembly solutions that implement SignalR.*
+
+:::moniker range=">= aspnetcore-6.0"
+
+If form processing fails because the component's form payload has exceeded the maximum incoming SignalR message size permitted for hub methods, the form can adopt [streaming JS interop](xref:blazor/js-interop/call-dotnet-from-javascript#stream-from-javascript-to-net) without increasing the message size limit. For more information on the size limit and the error thrown, see <xref:blazor/fundamentals/signalr#maximum-receive-message-size>.
+
+In the following example a text area (`<textarea>`) is used with streaming JS interop to move up to 50,000 bytes of data to the server.
+
+Add a JavaScript (JS) `getText` function to the app:
+
+```javascript
+window.getText = (elem) => {
+  const textValue = elem.value;
+  const utf8Encoder = new TextEncoder();
+  const encodedTextValue = utf8Encoder.encode(textValue);
+  return encodedTextValue;
+};
+```
+
+For information on where to place JS in a Blazor app, see <xref:blazor/js-interop/index#javaScript-location>.
+
+`ExampleModel2.cs`:
+
+```csharp
+public class ExampleModel2
+{
+    public string TextAreaValue { get; set; } = string.Empty;
+}
+```
+
+Due to security considerations, zero-length streams aren't permitted for streaming JS Interop. Therefore, the following `FormExample10` component traps a <xref:Microsoft.JSInterop.JSException> and returns an empty string if the text area is blank when the form is submitted.
+
+`Pages/FormExample10.razor`:
+
+```razor
+@page "/form-example-10"
+@inject IJSRuntime JS
+@inject ILogger<FormExample10> Logger
+
+<h1>Stream form data with JS interop</h1>
+
+<EditForm Model="@exampleModel" OnSubmit="@HandleSubmit">
+    <p>
+        <label>
+            &lt;textarea&gt; value streamed for assignment to 
+            <code>TextAreaValue (&lt;= 50,000 characters)</code>:
+            <textarea @ref="largeTextArea" />
+        </label>
+    </p>
+
+    <button type="submit">Submit</button>
+</EditForm>
+
+<p>
+    TextAreaValue length: @exampleModel.TextAreaValue1.Length
+</p>
+
+@code {
+    private ExampleModel2 exampleModel = new();
+    private ElementReference largeTextArea;
+
+    private async Task HandleSubmit()
+    {
+        exampleModel.TextAreaValue = await GetTextAsync();
+
+        Logger.LogInformation("TextAreaValue length: {Length}", 
+            exampleModel.TextAreaValue.Length);
+    }
+
+    public async Task<string> GetTextAsync()
+    {
+        try
+        {
+            var streamRef = 
+                await JS.InvokeAsync<IJSStreamReference>("getText", largeTextArea);
+            var stream = await streamRef.OpenReadStreamAsync(maxAllowedSize: 50_000);
+            var streamReader = new StreamReader(stream);
+
+            return await streamReader.ReadToEndAsync();
+        }
+        catch (JSException jsException)
+        {
+            if (jsException.InnerException is 
+                    ArgumentOutOfRangeException outOfRangeException &&
+                outOfRangeException.ActualValue is not null &&
+                outOfRangeException.ActualValue is long actualLength &&
+                actualLength == 0)
+            {
+                return string.Empty;
+            }
+
+            throw;
+        }
+    }
+}
+```
+
+:::moniker-end
+
+:::moniker range="< aspnetcore-6.0"
+
+If form processing fails because the component's form payload has exceeded the maximum incoming SignalR message size permitted for hub methods, the message size limit can be increased. For more information on the size limit and the error thrown, see <xref:blazor/fundamentals/signalr#maximum-receive-message-size>.
+
+:::moniker-end
+
 ## Troubleshoot
 
+### EditForm parameter error
+
 > InvalidOperationException: EditForm requires a Model parameter, or an EditContext parameter, but not both.
 
 Confirm that the <xref:Microsoft.AspNetCore.Components.Forms.EditForm> assigns a <xref:Microsoft.AspNetCore.Components.Forms.EditForm.Model> **or** an <xref:Microsoft.AspNetCore.Components.Forms.EditForm.EditContext>. Don't use both for the same form.
@@ -2253,6 +2370,16 @@ private ExampleModel exampleModel = new ExampleModel();
 
 :::moniker-end
 
+### Connection disconnected
+
+> Error: Connection disconnected with error 'Error: Server returned an error on close: Connection closed with an error.'.
+
+> System.IO.InvalidDataException: The maximum message size of 32768B was exceeded. The message size can be configured in AddHubOptions.
+
+For more information and guidance, see the following resources:
+
+* [Large form payloads and the SignalR message size limit](#large-form-payloads-and-the-signalr-message-size-limit)
+* <xref:blazor/fundamentals/signalr#maximum-receive-message-size>
 
 ## Additional resources
 
diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md
index 68afaedb19f9..cfd97f409458 100644
--- a/aspnetcore/blazor/fundamentals/signalr.md
+++ b/aspnetcore/blazor/fundamentals/signalr.md
@@ -246,6 +246,103 @@ services.AddServerSideBlazor()
 
 For information on Blazor Server's memory model, see <xref:blazor/host-and-deploy/server#blazor-server-memory-model>.
 
+## Maximum receive message size
+
+*This section only applies to Blazor Server apps and hosted Blazor WebAssembly solutions that implement SignalR.*
+
+The maximum incoming SignalR message size permitted for hub methods is limited by the <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize?displayProperty=nameWithType> (default: 32 KB). SignalR messages larger than <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> throw an error. The framework doesn't impose a limit on the size of a SignalR message from the hub to a client.
+
+When SignalR logging isn't set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), a message size error only appears in the browser's developer tools console:
+
+> Error: Connection disconnected with error 'Error: Server returned an error on close: Connection closed with an error.'.
+
+When [SignalR server-side logging](xref:signalr/diagnostics#server-side-logging) is set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), server-side logging surfaces an <xref:System.IO.InvalidDataException> for a message size error.
+
+`appsettings.Development.json`:
+
+```json
+{
+  "DetailedErrors": true,
+  "Logging": {
+    "LogLevel": {
+      ...
+      "Microsoft.AspNetCore.SignalR": "Debug"
+    }
+  }
+}
+```
+
+Error:
+
+> System.IO.InvalidDataException: The maximum message size of 32768B was exceeded. The message size can be configured in AddHubOptions.
+
+:::moniker range=">= aspnetcore-6.0"
+
+One approach involves increasing the limit by setting <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> in `Program.cs`. The following example sets the maximum receive message size to 64 KB:
+
+```csharp
+builder.Services.AddServerSideBlazor()
+    .AddHubOptions(options => options.MaximumReceiveMessageSize = 64 * 1024);
+```
+
+Increasing the SignalR incoming message size limit comes at the cost of requiring more server resources, and it increases the risk of [Denial of service (DoS) attacks](xref:blazor/security/server/threat-mitigation#denial-of-service-dos-attacks). Additionally, reading a large amount of content in to memory as strings or byte arrays can also result in allocations that work poorly with the garbage collector, resulting in additional performance penalties.
+
+A better option for reading large payloads is to send the content in smaller chunks and process the payload as a <xref:System.IO.Stream>. This can be used when reading large JavaScript (JS) interop JSON payloads or if JS interop data is available as raw bytes. For an example that demonstrates sending large binary payloads in Blazor Server that uses techniques similar to the [`InputFile` component](xref:blazor/file-uploads), see the [Binary Submit sample app](https://github.com/aspnet/samples/tree/main/samples/aspnetcore/blazor/BinarySubmit) and the [Blazor `InputLargeTextArea` Component Sample](https://github.com/aspnet/samples/tree/main/samples/aspnetcore/blazor/InputLargeTextArea).
+
+[!INCLUDE[](~/includes/aspnetcore-repo-ref-source-links.md)]
+
+Forms that process large payloads over SignalR can also use streaming JS interop directly. For more information, see <xref:blazor/js-interop/call-dotnet-from-javascript#stream-from-javascript-to-net>. For a forms example that streams `<textarea>` data in a Blazor Server app, see <xref:blazor/forms-and-input-components#large-form-payloads-and-the-signalr-message-size-limit>.
+
+:::moniker-end
+
+:::moniker range="< aspnetcore-6.0"
+
+Increase the limit by setting <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> in `Startup.ConfigureServices`:
+
+```csharp
+services.AddServerSideBlazor()
+    .AddHubOptions(options => options.MaximumReceiveMessageSize = 64 * 1024);
+```
+
+Increasing the SignalR incoming message size limit comes at the cost of requiring more server resources, and it increases the risk of [Denial of service (DoS) attacks](xref:blazor/security/server/threat-mitigation#denial-of-service-dos-attacks). Additionally, reading a large amount of content in to memory as strings or byte arrays can also result in allocations that work poorly with the garbage collector, resulting in additional performance penalties.
+
+:::moniker-end
+
+Consider the following guidance when developing code that transfers a large amount of data:
+
+:::moniker range=">= aspnetcore-6.0"
+
+* Leverage the native streaming JS interop support to transfer data larger than the SignalR incoming message size limit:
+  * <xref:blazor/js-interop/call-javascript-from-dotnet#stream-from-net-to-javascript>
+  * <xref:blazor/js-interop/call-dotnet-from-javascript#stream-from-javascript-to-net>
+  * Form payload example: <xref:blazor/forms-and-input-components#large-form-payloads-and-the-signalr-message-size-limit>
+* General tips:
+  * Don't allocate large objects in JS and C# code.
+  * Free consumed memory when the process is completed or cancelled.
+  * Enforce the following additional requirements for security purposes:
+    * Declare the maximum file or data size that can be passed.
+    * Declare the minimum upload rate from the client to the server.
+  * After the data is received by the server, the data can be:
+    * Temporarily stored in a memory buffer until all of the segments are collected.
+    * Consumed immediately. For example, the data can be stored immediately in a database or written to disk as each segment is received.
+
+:::moniker-end
+
+:::moniker range="< aspnetcore-6.0"
+
+* Slice the data into smaller pieces, and send the data segments sequentially until all of the data is received by the server.
+* Don't allocate large objects in JS and C# code.
+* Don't block the main UI thread for long periods when sending or receiving data.
+* Free consumed memory when the process is completed or cancelled.
+* Enforce the following additional requirements for security purposes:
+  * Declare the maximum file or data size that can be passed.
+  * Declare the minimum upload rate from the client to the server.
+* After the data is received by the server, the data can be:
+  * Temporarily stored in a memory buffer until all of the segments are collected.
+  * Consumed immediately. For example, the data can be stored immediately in a database or written to disk as each segment is received.
+
+:::moniker-end
+
 ## Blazor Hub endpoint route configuration (Blazor Server)
 
 In `Program.cs`, Blazor Server apps call <xref:Microsoft.AspNetCore.Builder.ComponentEndpointRouteBuilderExtensions.MapBlazorHub%2A> to map the Blazor <xref:Microsoft.AspNetCore.SignalR.Hub> to the app's default path. The Blazor Server script (`blazor.server.js`) automatically points to the endpoint created by <xref:Microsoft.AspNetCore.Builder.ComponentEndpointRouteBuilderExtensions.MapBlazorHub%2A>.
diff --git a/aspnetcore/blazor/includes/js-interop/3.1/size-limits.md b/aspnetcore/blazor/includes/js-interop/3.1/size-limits.md
deleted file mode 100644
index 72b7114b75ca..000000000000
--- a/aspnetcore/blazor/includes/js-interop/3.1/size-limits.md
+++ /dev/null
@@ -1,55 +0,0 @@
-*This section only applies to Blazor Server apps. In Blazor WebAssembly, the framework doesn't impose a limit on the size of JavaScript (JS) interop inputs and outputs.*
-
-In Blazor Server, JS interop calls are limited in size by the maximum incoming SignalR message size permitted for hub methods, which is enforced by <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize?displayProperty=nameWithType> (default: 32 KB). JS to .NET SignalR messages larger than <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> throw an error. The framework doesn't impose a limit on the size of a SignalR message from the hub to a client.
-
-When SignalR logging isn't set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), a message size error only appears in the browser's developer tools console:
-
-> Error: Connection disconnected with error 'Error: Server returned an error on close: Connection closed with an error.'.
-
-When [SignalR server-side logging](xref:signalr/diagnostics#server-side-logging) is set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), server-side logging surfaces an <xref:System.IO.InvalidDataException> for a message size error.
-
-`appsettings.Development.json`:
-
-```json
-{
-  "DetailedErrors": true,
-  "Logging": {
-    "LogLevel": {
-      "Default": "Information",
-      "Microsoft": "Warning",
-      "Microsoft.Hosting.Lifetime": "Information",
-      "Microsoft.AspNetCore.SignalR": "Debug"
-    }
-  }
-}
-```
-
-Error:
-
-> System.IO.InvalidDataException: The maximum message size of 32768B was exceeded. The message size can be configured in AddHubOptions.
-
-Increase the limit by setting <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> in `Startup.ConfigureServices`:
-
-```csharp
-services.AddServerSideBlazor()
-    .AddHubOptions(options => options.MaximumReceiveMessageSize = 64 * 1024);
-```
-
-Increasing the SignalR incoming message size limit comes at the cost of requiring more server resources, and it exposes the server to increased risks from a malicious user. Additionally, reading a large amount of content in to memory as strings or byte arrays can also result in allocations that work poorly with the garbage collector, resulting in additional performance penalties.
-
-One option for reading large payloads is to send the content in smaller chunks and process the payload as a <xref:System.IO.Stream>. This can be used when reading large JSON payloads or if data is available in JS as raw bytes. For an example that demonstrates sending large binary payloads in Blazor Server that uses techniques similar to the [`InputFile` component](xref:blazor/file-uploads), see the [Binary Submit sample app](https://github.com/aspnet/samples/tree/main/samples/aspnetcore/blazor/BinarySubmit).
-
-[!INCLUDE[](~/includes/aspnetcore-repo-ref-source-links.md)]
-
-Consider the following guidance when developing code that transfers a large amount of data between JS and Blazor in Blazor Server apps:
-
-* Slice the data into smaller pieces, and send the data segments sequentially until all of the data is received by the server.
-* Don't allocate large objects in JS and C# code.
-* Don't block the main UI thread for long periods when sending or receiving data.
-* Free consumed memory when the process is completed or cancelled.
-* Enforce the following additional requirements for security purposes:
-  * Declare the maximum file or data size that can be passed.
-  * Declare the minimum upload rate from the client to the server.
-* After the data is received by the server, the data can be:
-  * Temporarily stored in a memory buffer until all of the segments are collected.
-  * Consumed immediately. For example, the data can be stored immediately in a database or written to disk as each segment is received.
diff --git a/aspnetcore/blazor/includes/js-interop/5.0/size-limits.md b/aspnetcore/blazor/includes/js-interop/5.0/size-limits.md
deleted file mode 100644
index 72b7114b75ca..000000000000
--- a/aspnetcore/blazor/includes/js-interop/5.0/size-limits.md
+++ /dev/null
@@ -1,55 +0,0 @@
-*This section only applies to Blazor Server apps. In Blazor WebAssembly, the framework doesn't impose a limit on the size of JavaScript (JS) interop inputs and outputs.*
-
-In Blazor Server, JS interop calls are limited in size by the maximum incoming SignalR message size permitted for hub methods, which is enforced by <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize?displayProperty=nameWithType> (default: 32 KB). JS to .NET SignalR messages larger than <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> throw an error. The framework doesn't impose a limit on the size of a SignalR message from the hub to a client.
-
-When SignalR logging isn't set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), a message size error only appears in the browser's developer tools console:
-
-> Error: Connection disconnected with error 'Error: Server returned an error on close: Connection closed with an error.'.
-
-When [SignalR server-side logging](xref:signalr/diagnostics#server-side-logging) is set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), server-side logging surfaces an <xref:System.IO.InvalidDataException> for a message size error.
-
-`appsettings.Development.json`:
-
-```json
-{
-  "DetailedErrors": true,
-  "Logging": {
-    "LogLevel": {
-      "Default": "Information",
-      "Microsoft": "Warning",
-      "Microsoft.Hosting.Lifetime": "Information",
-      "Microsoft.AspNetCore.SignalR": "Debug"
-    }
-  }
-}
-```
-
-Error:
-
-> System.IO.InvalidDataException: The maximum message size of 32768B was exceeded. The message size can be configured in AddHubOptions.
-
-Increase the limit by setting <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> in `Startup.ConfigureServices`:
-
-```csharp
-services.AddServerSideBlazor()
-    .AddHubOptions(options => options.MaximumReceiveMessageSize = 64 * 1024);
-```
-
-Increasing the SignalR incoming message size limit comes at the cost of requiring more server resources, and it exposes the server to increased risks from a malicious user. Additionally, reading a large amount of content in to memory as strings or byte arrays can also result in allocations that work poorly with the garbage collector, resulting in additional performance penalties.
-
-One option for reading large payloads is to send the content in smaller chunks and process the payload as a <xref:System.IO.Stream>. This can be used when reading large JSON payloads or if data is available in JS as raw bytes. For an example that demonstrates sending large binary payloads in Blazor Server that uses techniques similar to the [`InputFile` component](xref:blazor/file-uploads), see the [Binary Submit sample app](https://github.com/aspnet/samples/tree/main/samples/aspnetcore/blazor/BinarySubmit).
-
-[!INCLUDE[](~/includes/aspnetcore-repo-ref-source-links.md)]
-
-Consider the following guidance when developing code that transfers a large amount of data between JS and Blazor in Blazor Server apps:
-
-* Slice the data into smaller pieces, and send the data segments sequentially until all of the data is received by the server.
-* Don't allocate large objects in JS and C# code.
-* Don't block the main UI thread for long periods when sending or receiving data.
-* Free consumed memory when the process is completed or cancelled.
-* Enforce the following additional requirements for security purposes:
-  * Declare the maximum file or data size that can be passed.
-  * Declare the minimum upload rate from the client to the server.
-* After the data is received by the server, the data can be:
-  * Temporarily stored in a memory buffer until all of the segments are collected.
-  * Consumed immediately. For example, the data can be stored immediately in a database or written to disk as each segment is received.
diff --git a/aspnetcore/blazor/includes/js-interop/6.0/size-limits.md b/aspnetcore/blazor/includes/js-interop/6.0/size-limits.md
deleted file mode 100644
index c8d54e562ff6..000000000000
--- a/aspnetcore/blazor/includes/js-interop/6.0/size-limits.md
+++ /dev/null
@@ -1,53 +0,0 @@
-*This section only applies to Blazor Server apps. In Blazor WebAssembly, the framework doesn't impose a limit on the size of JavaScript (JS) interop inputs and outputs.*
-
-In Blazor Server, JS interop calls are limited in size by the maximum incoming SignalR message size permitted for hub methods, which is enforced by <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize?displayProperty=nameWithType> (default: 32 KB). JS to .NET SignalR messages larger than <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> throw an error. The framework doesn't impose a limit on the size of a SignalR message from the hub to a client.
-
-When SignalR logging isn't set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), a message size error only appears in the browser's developer tools console:
-
-> Error: Connection disconnected with error 'Error: Server returned an error on close: Connection closed with an error.'.
-
-When [SignalR server-side logging](xref:signalr/diagnostics#server-side-logging) is set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), server-side logging surfaces an <xref:System.IO.InvalidDataException> for a message size error.
-
-`appsettings.Development.json`:
-
-```json
-{
-  "DetailedErrors": true,
-  "Logging": {
-    "LogLevel": {
-      "Default": "Information",
-      "Microsoft": "Warning",
-      "Microsoft.Hosting.Lifetime": "Information",
-      "Microsoft.AspNetCore.SignalR": "Debug"
-    }
-  }
-}
-```
-
-Error:
-
-> System.IO.InvalidDataException: The maximum message size of 32768B was exceeded. The message size can be configured in AddHubOptions.
-
-Increase the limit by setting <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> in `Program.cs`. The following example sets the maximum receive message size to 64 KB:
-
-```csharp
-builder.Services.AddServerSideBlazor()
-    .AddHubOptions(options => options.MaximumReceiveMessageSize = 64 * 1024);
-```
-
-Increasing the SignalR incoming message size limit comes at the cost of requiring more server resources, and it exposes the server to increased risks from a malicious user. Additionally, reading a large amount of content in to memory as strings or byte arrays can also result in allocations that work poorly with the garbage collector, resulting in additional performance penalties.
-
-Consider the following guidance when developing code that transfers a large amount of data between JS and Blazor in Blazor Server apps:
-
-* Leverage the native streaming interop support to transfer data larger than the SignalR incoming message size limit:
-  * <xref:blazor/js-interop/call-javascript-from-dotnet#stream-from-net-to-javascript>
-  * <xref:blazor/js-interop/call-dotnet-from-javascript#stream-from-javascript-to-net>
-* General tips:
-  * Don't allocate large objects in JS and C# code.
-  * Free consumed memory when the process is completed or cancelled.
-  * Enforce the following additional requirements for security purposes:
-    * Declare the maximum file or data size that can be passed.
-    * Declare the minimum upload rate from the client to the server.
-  * After the data is received by the server, the data can be:
-    * Temporarily stored in a memory buffer until all of the segments are collected.
-    * Consumed immediately. For example, the data can be stored immediately in a database or written to disk as each segment is received.
diff --git a/aspnetcore/blazor/includes/js-interop/7.0/size-limits.md b/aspnetcore/blazor/includes/js-interop/7.0/size-limits.md
deleted file mode 100644
index c8d54e562ff6..000000000000
--- a/aspnetcore/blazor/includes/js-interop/7.0/size-limits.md
+++ /dev/null
@@ -1,53 +0,0 @@
-*This section only applies to Blazor Server apps. In Blazor WebAssembly, the framework doesn't impose a limit on the size of JavaScript (JS) interop inputs and outputs.*
-
-In Blazor Server, JS interop calls are limited in size by the maximum incoming SignalR message size permitted for hub methods, which is enforced by <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize?displayProperty=nameWithType> (default: 32 KB). JS to .NET SignalR messages larger than <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> throw an error. The framework doesn't impose a limit on the size of a SignalR message from the hub to a client.
-
-When SignalR logging isn't set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), a message size error only appears in the browser's developer tools console:
-
-> Error: Connection disconnected with error 'Error: Server returned an error on close: Connection closed with an error.'.
-
-When [SignalR server-side logging](xref:signalr/diagnostics#server-side-logging) is set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), server-side logging surfaces an <xref:System.IO.InvalidDataException> for a message size error.
-
-`appsettings.Development.json`:
-
-```json
-{
-  "DetailedErrors": true,
-  "Logging": {
-    "LogLevel": {
-      "Default": "Information",
-      "Microsoft": "Warning",
-      "Microsoft.Hosting.Lifetime": "Information",
-      "Microsoft.AspNetCore.SignalR": "Debug"
-    }
-  }
-}
-```
-
-Error:
-
-> System.IO.InvalidDataException: The maximum message size of 32768B was exceeded. The message size can be configured in AddHubOptions.
-
-Increase the limit by setting <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> in `Program.cs`. The following example sets the maximum receive message size to 64 KB:
-
-```csharp
-builder.Services.AddServerSideBlazor()
-    .AddHubOptions(options => options.MaximumReceiveMessageSize = 64 * 1024);
-```
-
-Increasing the SignalR incoming message size limit comes at the cost of requiring more server resources, and it exposes the server to increased risks from a malicious user. Additionally, reading a large amount of content in to memory as strings or byte arrays can also result in allocations that work poorly with the garbage collector, resulting in additional performance penalties.
-
-Consider the following guidance when developing code that transfers a large amount of data between JS and Blazor in Blazor Server apps:
-
-* Leverage the native streaming interop support to transfer data larger than the SignalR incoming message size limit:
-  * <xref:blazor/js-interop/call-javascript-from-dotnet#stream-from-net-to-javascript>
-  * <xref:blazor/js-interop/call-dotnet-from-javascript#stream-from-javascript-to-net>
-* General tips:
-  * Don't allocate large objects in JS and C# code.
-  * Free consumed memory when the process is completed or cancelled.
-  * Enforce the following additional requirements for security purposes:
-    * Declare the maximum file or data size that can be passed.
-    * Declare the minimum upload rate from the client to the server.
-  * After the data is received by the server, the data can be:
-    * Temporarily stored in a memory buffer until all of the segments are collected.
-    * Consumed immediately. For example, the data can be stored immediately in a database or written to disk as each segment is received.
diff --git a/aspnetcore/blazor/includes/js-interop/8.0/size-limits.md b/aspnetcore/blazor/includes/js-interop/8.0/size-limits.md
deleted file mode 100644
index c8d54e562ff6..000000000000
--- a/aspnetcore/blazor/includes/js-interop/8.0/size-limits.md
+++ /dev/null
@@ -1,53 +0,0 @@
-*This section only applies to Blazor Server apps. In Blazor WebAssembly, the framework doesn't impose a limit on the size of JavaScript (JS) interop inputs and outputs.*
-
-In Blazor Server, JS interop calls are limited in size by the maximum incoming SignalR message size permitted for hub methods, which is enforced by <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize?displayProperty=nameWithType> (default: 32 KB). JS to .NET SignalR messages larger than <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> throw an error. The framework doesn't impose a limit on the size of a SignalR message from the hub to a client.
-
-When SignalR logging isn't set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), a message size error only appears in the browser's developer tools console:
-
-> Error: Connection disconnected with error 'Error: Server returned an error on close: Connection closed with an error.'.
-
-When [SignalR server-side logging](xref:signalr/diagnostics#server-side-logging) is set to [Debug](xref:Microsoft.Extensions.Logging.LogLevel) or [Trace](xref:Microsoft.Extensions.Logging.LogLevel), server-side logging surfaces an <xref:System.IO.InvalidDataException> for a message size error.
-
-`appsettings.Development.json`:
-
-```json
-{
-  "DetailedErrors": true,
-  "Logging": {
-    "LogLevel": {
-      "Default": "Information",
-      "Microsoft": "Warning",
-      "Microsoft.Hosting.Lifetime": "Information",
-      "Microsoft.AspNetCore.SignalR": "Debug"
-    }
-  }
-}
-```
-
-Error:
-
-> System.IO.InvalidDataException: The maximum message size of 32768B was exceeded. The message size can be configured in AddHubOptions.
-
-Increase the limit by setting <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> in `Program.cs`. The following example sets the maximum receive message size to 64 KB:
-
-```csharp
-builder.Services.AddServerSideBlazor()
-    .AddHubOptions(options => options.MaximumReceiveMessageSize = 64 * 1024);
-```
-
-Increasing the SignalR incoming message size limit comes at the cost of requiring more server resources, and it exposes the server to increased risks from a malicious user. Additionally, reading a large amount of content in to memory as strings or byte arrays can also result in allocations that work poorly with the garbage collector, resulting in additional performance penalties.
-
-Consider the following guidance when developing code that transfers a large amount of data between JS and Blazor in Blazor Server apps:
-
-* Leverage the native streaming interop support to transfer data larger than the SignalR incoming message size limit:
-  * <xref:blazor/js-interop/call-javascript-from-dotnet#stream-from-net-to-javascript>
-  * <xref:blazor/js-interop/call-dotnet-from-javascript#stream-from-javascript-to-net>
-* General tips:
-  * Don't allocate large objects in JS and C# code.
-  * Free consumed memory when the process is completed or cancelled.
-  * Enforce the following additional requirements for security purposes:
-    * Declare the maximum file or data size that can be passed.
-    * Declare the minimum upload rate from the client to the server.
-  * After the data is received by the server, the data can be:
-    * Temporarily stored in a memory buffer until all of the segments are collected.
-    * Consumed immediately. For example, the data can be stored immediately in a database or written to disk as each segment is received.
diff --git a/aspnetcore/blazor/javascript-interoperability/call-dotnet-from-javascript.md b/aspnetcore/blazor/javascript-interoperability/call-dotnet-from-javascript.md
index c0f38510a719..4fbe2cefe62d 100644
--- a/aspnetcore/blazor/javascript-interoperability/call-dotnet-from-javascript.md
+++ b/aspnetcore/blazor/javascript-interoperability/call-dotnet-from-javascript.md
@@ -1310,33 +1310,7 @@ In the preceding example:
 
 <xref:blazor/js-interop/call-javascript-from-dotnet#stream-from-net-to-javascript> covers the reverse operation, streaming from .NET to JavaScript using a <xref:Microsoft.JSInterop.DotNetStreamReference>.
 
-<xref:blazor/file-uploads> covers how to upload a file in Blazor.
-
-:::moniker-end
-
-## Size limits on JavaScript interop calls
-
-:::moniker range=">= aspnetcore-7.0"
-
-[!INCLUDE[](~/blazor/includes/js-interop/7.0/size-limits.md)]
-
-:::moniker-end
-
-:::moniker range=">= aspnetcore-6.0 < aspnetcore-7.0"
-
-[!INCLUDE[](~/blazor/includes/js-interop/6.0/size-limits.md)]
-
-:::moniker-end
-
-:::moniker range=">= aspnetcore-5.0 < aspnetcore-6.0"
-
-[!INCLUDE[](~/blazor/includes/js-interop/5.0/size-limits.md)]
-
-:::moniker-end
-
-:::moniker range="< aspnetcore-5.0"
-
-[!INCLUDE[](~/blazor/includes/js-interop/3.1/size-limits.md)]
+<xref:blazor/file-uploads> covers how to upload a file in Blazor. For a forms example that streams `<textarea>` data in a Blazor Server app, see <xref:blazor/forms-and-input-components#large-form-payloads-and-the-signalr-message-size-limit>.
 
 :::moniker-end
 
diff --git a/aspnetcore/blazor/javascript-interoperability/call-javascript-from-dotnet.md b/aspnetcore/blazor/javascript-interoperability/call-javascript-from-dotnet.md
index dd855c6defc8..3d8e099be2d7 100644
--- a/aspnetcore/blazor/javascript-interoperability/call-javascript-from-dotnet.md
+++ b/aspnetcore/blazor/javascript-interoperability/call-javascript-from-dotnet.md
@@ -806,32 +806,6 @@ Objects that contain circular references can't be serialized on the client for e
 * .NET method calls.
 * JavaScript method calls from C# when the return type has circular references.
 
-## Size limits on JavaScript interop calls
-
-:::moniker range=">= aspnetcore-7.0"
-
-[!INCLUDE[](~/blazor/includes/js-interop/7.0/size-limits.md)]
-
-:::moniker-end
-
-:::moniker range=">= aspnetcore-6.0 < aspnetcore-7.0"
-
-[!INCLUDE[](~/blazor/includes/js-interop/6.0/size-limits.md)]
-
-:::moniker-end
-
-:::moniker range=">= aspnetcore-5.0 < aspnetcore-6.0"
-
-[!INCLUDE[](~/blazor/includes/js-interop/5.0/size-limits.md)]
-
-:::moniker-end
-
-:::moniker range="< aspnetcore-5.0"
-
-[!INCLUDE[](~/blazor/includes/js-interop/3.1/size-limits.md)]
-
-:::moniker-end
-
 :::moniker range=">= aspnetcore-6.0"
 
 ## JavaScript libraries that render UI
diff --git a/aspnetcore/blazor/javascript-interoperability/index.md b/aspnetcore/blazor/javascript-interoperability/index.md
index 0f65ac816ada..48e917d3e9dc 100644
--- a/aspnetcore/blazor/javascript-interoperability/index.md
+++ b/aspnetcore/blazor/javascript-interoperability/index.md
@@ -296,3 +296,9 @@ For more information, see:
 
 * <xref:blazor/fundamentals/environments>
 * <xref:performance/caching/response>
+
+## Size limits on JavaScript interop calls
+
+*This section only applies to Blazor Server apps. In Blazor WebAssembly, the framework doesn't impose a limit on the size of JavaScript (JS) interop inputs and outputs.*
+
+In Blazor Server, JS interop calls passing data from the client to the server are limited in size by the maximum incoming SignalR message size permitted for hub methods, which is enforced by <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize?displayProperty=nameWithType> (default: 32 KB). JS to .NET SignalR messages larger than <xref:Microsoft.AspNetCore.SignalR.HubOptions.MaximumReceiveMessageSize> throw an error. The framework doesn't impose a limit on the size of a SignalR message from the hub to a client. For more information on the size limit, error messages, and guidance on dealing with message size limits, see <xref:blazor/fundamentals/signalr#maximum-receive-message-size>.
diff --git a/aspnetcore/host-and-deploy/linux-nginx.md b/aspnetcore/host-and-deploy/linux-nginx.md
index d285beb74352..8eb51cce13fc 100644
--- a/aspnetcore/host-and-deploy/linux-nginx.md
+++ b/aspnetcore/host-and-deploy/linux-nginx.md
@@ -365,7 +365,7 @@ Close off all external ports that aren't in use. Uncomplicated firewall (ufw) pr
 # [Ubuntu](#tab/linux-ubuntu)
 
 > [!WARNING]
-> A firewall prevents access to the whole system if not configured correctly. Failure to specify the correct SSH port effectively locks you out of the system if you are using SSH to connect to it. The default port is 22. For more information, see the [introduction to ufw](https://help.ubuntu.com/community/UFW) and the [manual](https://manpages.ubuntu.com/manpages/bionic/man8/ufw.8.html).
+> A firewall prevents access to the whole system if not configured correctly. Failure to specify the correct SSH port effectively locks you out of the system if you are using SSH to connect to it. The default port is 22. For more information, see the [introduction to ufw](https://help.ubuntu.com/community/UFW) and the [manual](https://manpages.ubuntu.com/manpages/lunar/en/man8/ufw.8.html).
 
 Install `ufw` and configure it to allow traffic on any ports needed.
 
diff --git a/aspnetcore/host-and-deploy/linux-nginx/includes/linux-nginx5.md b/aspnetcore/host-and-deploy/linux-nginx/includes/linux-nginx5.md
index ecd264ab91fe..37bd9cb6f885 100644
--- a/aspnetcore/host-and-deploy/linux-nginx/includes/linux-nginx5.md
+++ b/aspnetcore/host-and-deploy/linux-nginx/includes/linux-nginx5.md
@@ -311,7 +311,7 @@ Linux Security Modules (LSM) is a framework that's part of the Linux kernel sinc
 Close off all external ports that aren't in use. Uncomplicated firewall (ufw) provides a front end for `iptables` by providing a CLI for configuring the firewall.
 
 > [!WARNING]
-> A firewall will prevent access to the whole system if not configured correctly. Failure to specify the correct SSH port will effectively lock you out of the system if you are using SSH to connect to it. The default port is 22. For more information, see the [introduction to ufw](https://help.ubuntu.com/community/UFW) and the [manual](https://manpages.ubuntu.com/manpages/bionic/man8/ufw.8.html).
+> A firewall will prevent access to the whole system if not configured correctly. Failure to specify the correct SSH port will effectively lock you out of the system if you are using SSH to connect to it. The default port is 22. For more information, see the [introduction to ufw](https://help.ubuntu.com/community/UFW) and the [manual](https://manpages.ubuntu.com/manpages/lunar/en/man8/ufw.8.html).
 
 Install `ufw` and configure it to allow traffic on any ports needed.
 
@@ -757,7 +757,7 @@ Linux Security Modules (LSM) is a framework that's part of the Linux kernel sinc
 Close off all external ports that aren't in use. Uncomplicated firewall (ufw) provides a front end for `iptables` by providing a CLI for configuring the firewall.
 
 > [!WARNING]
-> A firewall will prevent access to the whole system if not configured correctly. Failure to specify the correct SSH port will effectively lock you out of the system if you are using SSH to connect to it. The default port is 22. For more information, see the [introduction to ufw](https://help.ubuntu.com/community/UFW) and the [manual](https://manpages.ubuntu.com/manpages/bionic/man8/ufw.8.html).
+> A firewall will prevent access to the whole system if not configured correctly. Failure to specify the correct SSH port will effectively lock you out of the system if you are using SSH to connect to it. The default port is 22. For more information, see the [introduction to ufw](https://help.ubuntu.com/community/UFW) and the [manual](https://manpages.ubuntu.com/manpages/lunar/en/man8/ufw.8.html).
 
 Install `ufw` and configure it to allow traffic on any ports needed.