Steps to reproduce the issue

1. Log in to the Joomla administrator backend.
2. Navigate to Content → Media.
3. Open the browser’s Developer Tools → Network panel.
4. Click Upload → choose an image file (e.g. logo.png, ~1 MB).
5. Observe the request that is sent to /administrator/index.php?option=com_media&format=json&mediatypes=0,1,2,3&task=api.files&path=local-images%3A%2F.
   • The request method is POST.
   • Content-Type is application/json.
   • The body is a single JSON string that contains the entire image data (Base64‑encoded).

Expected result

The upload should use the standard multipart/form‑data encoding (exactly like the upload of extensions or other media types). The request should contain a boundary parameter, a Content-Disposition header with the filename, and the raw binary data as a separate part. This ensures:

• Streaming of the file to disk (no full‑file load into memory).
• No Base64 overhead (≈ 33 % smaller payload).
• Consistent behaviour across all media uploads.

Actual result

• The image file is transmitted as a single JSON payload that is Base64‑encoded.
• The server must read the entire request into memory, decode the Base64 string, then write the file to disk.
• The resulting payload is larger, increases network latency, and can hit PHP’s memory_limit , post_max_size limits or even ModSec default values blocking these requests.

System information (as much as possible)

Note: The large Content-Length (≈ 1.39 MB) is visible in the network tab and matches the size of the image plus the Base64 overhead.

Additional comments

• ModSecurity compatibility: A default Joomla installation does not work with ModSecurity because the ModSecurity rule SecRequestBodyNoFilesLimit (default limit 1 MB) is hit when uploading JSON payloads (Image 1MB). This is a common issue for many shared hosts that employ ModSecurity; Joomla’s JSON‑based upload is therefore non‑compliant with widely‑deployed web‑application firewall rules.