--- a/Sphinx/source/faq/db-benchmark.rst	Wed Nov 12 09:45:35 2025 +0100
+++ b/Sphinx/source/faq/db-benchmark.rst	Wed Nov 12 13:08:40 2025 +0100
@@ -42,7 +42,7 @@
 The fourth plot shows the time required to retrieve a single instance through :ref:`DICOMweb WADO-RS <dicomweb>`.
 This is typical of API calls performed by the :ref:`Stone Web viewer <stone_webviewer>` or the :ref:`OHIF viewer <ohif>`.
 
-The bad performance of the DICOMWeb plugin with SQLite to compute the ``metadata`` cache can 
+The bad performance of the DICOMweb plugin with SQLite to compute the ``metadata`` cache can 
 actually be explained by the fourth plot that shows that even simple search operations in the database get slower.
 
 
@@ -54,7 +54,7 @@
 
 Typically, if you are only handling ``CR, DX`` or simple ``US`` images, SQLite is a very good option.
 SQLite also remains a good option if you are using Orthanc as a buffer to transfer, convert or sanitize images
-in a workflow, especially if you do not need the DICOMWeb plugin.
+in a workflow, especially if you do not need the DICOMweb plugin.
 
 As soon as you plan to store thousands of ``MR, CT, MG`` or other large image sets, you should
 switch to the :ref:`PostgreSQL <postgresql>`.

--- a/Sphinx/source/faq/main-dicom-tags.rst	Wed Nov 12 09:45:35 2025 +0100
+++ b/Sphinx/source/faq/main-dicom-tags.rst	Wed Nov 12 13:08:40 2025 +0100
@@ -164,13 +164,13 @@
     }
 
 
-DICOMWeb
+DICOMweb
 ========
 
 Below is a sample configuration that is well suited to
-optimize DICOMWeb routes in general in case you are using the 
+optimize DICOMweb routes in general in case you are using the 
 ``MainDicomTags`` metadata mode.  However, note that, from version
-1.15 of the :ref:`DICOMWeb plugin <dicomweb-server-metadata-config>`, you should favor the ``Full`` mode::
+1.15 of the :ref:`DICOMweb plugin <dicomweb-server-metadata-config>`, you should favor the ``Full`` mode::
 
     {
         "ExtraMainDicomTags" : {

--- a/Sphinx/source/faq/scalability.rst	Wed Nov 12 09:45:35 2025 +0100
+++ b/Sphinx/source/faq/scalability.rst	Wed Nov 12 13:08:40 2025 +0100
@@ -118,7 +118,7 @@
 
 * From Orthanc 1.11.0: you have the ability to add
   more :ref:`main DICOM tags <main-dicom-tags>` in the Orthanc Index 
-  to speed up C-Find, ``tools/find``, DICOMWeb QIDO-RS, WADO-RS and 
+  to speed up C-Find, ``tools/find``, DICOMweb QIDO-RS, WADO-RS and 
   especially WADO-RS Retrieve Metadata.
 
 * Make sure to carefully :ref:`read the logs <log>` in ``--verbose``

--- a/Sphinx/source/integrations/integrate-osirix-using-dicomweb.rst	Wed Nov 12 09:45:35 2025 +0100
+++ b/Sphinx/source/integrations/integrate-osirix-using-dicomweb.rst	Wed Nov 12 13:08:40 2025 +0100
@@ -1,6 +1,6 @@
 .. _integrate-osirix-using-dicomweb:
 
-Integrate Osirix using DICOMWeb
+Integrate Osirix using DICOMweb
 ===============================
 
 .. note:: The OsiriX team has a blog post entitled "`Installing
@@ -14,7 +14,7 @@
 -----------------------
 
 - In ``Preferences->Listener``, activate and configure AETitle and Port (e.g. Osirix 11112)
-- In ``Preferences->Locations->DICOMWeb Node``, add a DICOM Node:
+- In ``Preferences->Locations->DICOMweb Node``, add a DICOM Node:
 
   - with the URL of the Orthanc server
   - with the DICOMweb API path of Orthanc (default is ``/dicom-web``)
@@ -53,7 +53,7 @@
 
   DICOM_WEB_PLUGIN_ENABLED: "true"
 
-If using Orthanc in a docker container, map the Orthanc DICOMWeb Http Port. Eg in docker-compose file::
+If using Orthanc in a docker container, map the Orthanc DICOMweb Http Port. Eg in docker-compose file::
 
   ports:
     - "8042:8042"

--- a/Sphinx/source/plugins/python.rst	Wed Nov 12 09:45:35 2025 +0100
+++ b/Sphinx/source/plugins/python.rst	Wed Nov 12 13:08:40 2025 +0100
@@ -376,7 +376,7 @@
 Note however, that, as of Orthanc 1.12.9, the Orthanc plugin SDK
 does not support multiple plugins implementing the same route.
 Orthanc will actually accept e.g a Python plugin that overrides
-a DICOMWeb route but it is impossible to tell which route
+a DICOMweb route but it is impossible to tell which route
 will be called in the end since this depends on the registration 
 order of the plugins that is not deterministic.
 
@@ -761,7 +761,7 @@
 
 **Note:** In version 4.2, we have introduced a new version of the C-MOVE SCP 
 handler that can be registered through ``orthanc.RegisterMoveCallback2(CreateMoveCallback, GetMoveSizeCallback, ApplyMoveCallback, FreeMoveCallback)``.
-This `DICOM to DICOMWeb proxy sample project <https://github.com/orthanc-team/dicom-dicomweb-proxy/blob/main/proxy.py>`__ demonstrates how it can be used.
+This `DICOM to DICOMweb proxy sample project <https://github.com/orthanc-team/dicom-dicomweb-proxy/blob/main/proxy.py>`__ demonstrates how it can be used.
 
 
 .. _python_worklists:

--- a/Sphinx/source/plugins/python/extending-rest-api-2.py	Wed Nov 12 09:45:35 2025 +0100
+++ b/Sphinx/source/plugins/python/extending-rest-api-2.py	Wed Nov 12 13:08:40 2025 +0100
@@ -18,7 +18,7 @@
         instances = orthanc.RestApiGet(uri)
         output.AnswerBuffer(instances, "application/json")
 
-# reimplement a DICOMWeb /studies/../metadata route
+# reimplement a DICOMweb /studies/../metadata route
 def OnDicomWebStudiesMetadata(output, uri, **request):
     
     orthanc.LogWarning("My DICOMWEB /studies/../metadata")
@@ -39,8 +39,8 @@
 orthanc.RegisterRestCallback('/instances', OnInstances)
 
 # The code below should be avoided since you actually don't know which route will finally be called:
-# the one from the DICOMWeb plugin or the one from this python plugin
+# the one from the DICOMweb plugin or the one from this python plugin
 # orthanc.RegisterRestCallback('/dicom-web/studies/(.*)/metadata', OnDicomWebStudiesMetadata)
 
-# Therefore, you should use another base route to differentiate it from the DICOMWeb plugin route
+# Therefore, you should use another base route to differentiate it from the DICOMweb plugin route
 orthanc.RegisterRestCallback('/my-dicom-web/studies/(.*)/metadata', OnDicomWebStudiesMetadata)