---
title: "How to Increase PHP's post_max_size Value Using CloudLinux Selector in cPanel"
description: "Raise PHP's post_max_size in the cPanel Select PHP Version tool, pair it with upload_max_filesize, and fix upload forms that submit blank with no error."
url: "https://docs.noiz.ie/cpanel/how-to-increase-phps-post-max-size-value-using-cloudlinux-selector-in-cpanel/"
section: "cPanel"
categories:
  - "Control Panels > cPanel > PHP"
last_reviewed: "27 July 2026, against the current cPanel & WHM release with the Jupiter interface, and against the current CloudLinux PHP Selector"
---

# How to Increase PHP's post_max_size Value Using CloudLinux Selector in cPanel

On Noiz cPanel hosting that runs CloudLinux, the **Select PHP Version** tool (commonly called the CloudLinux PHP Selector) lets you raise `post_max_size` yourself, without editing a `php.ini` file or opening a support ticket. This guide shows you where the setting lives, what it actually controls, and why it almost always has to be changed together with `upload_max_filesize`.

`post_max_size` is the maximum size of an *entire* POST request body that PHP will accept. That is not just the file being uploaded. It covers every uploaded file in the form, every text field, every hidden field, and the multipart encoding overhead that wraps them. If you upload one 60 MB file through a form that also carries a title, a description and a security token, the request on the wire is slightly larger than 60 MB, and it is that larger figure that `post_max_size` is measured against.

**Last reviewed:** 27 July 2026, against the current cPanel & WHM release with the Jupiter interface, and against the current CloudLinux PHP Selector. This guide is written for Noiz hosting and is kept current against cPanel and CloudLinux. It complements, and does not replace, the official documentation linked below.

### Official Documentation Reference

- [PHP Manual: post\_max\_size](https://www.php.net/manual/en/ini.core.php#ini.post-max-size): the authoritative definition of the directive, its shorthand notation (`8M`, `1G`) and its interaction with `memory_limit`.
- [PHP Manual: Common Pitfalls in File Uploads](https://www.php.net/manual/en/features.file-upload.common-pitfalls.php): why an oversized POST arrives as an empty `$_POST` and `$_FILES` rather than as an error.
- [PHP Manual: upload\_max\_filesize](https://www.php.net/manual/en/ini.core.php#ini.upload-max-filesize): the companion directive that caps each individual file.
- [CloudLinux OS Components: PHP Selector](https://docs.cloudlinux.com/cloudlinuxos/cloudlinux_os_components/#php-selector): how the Selector stores per-version settings and where its limitations lie.
- [cPanel: MultiPHP INI Editor](https://docs.cpanel.net/cpanel/software/multiphp-ini-editor-for-cpanel/): the separate cPanel-native editor that some accounts have instead of, or alongside, the CloudLinux Selector.

## Prerequisites

- A Noiz cPanel hosting account and its login details.
- A note of the current `post_max_size` and `upload_max_filesize` values before you change anything, so you can put them back.
- The largest single upload you actually need to support, and a rough idea of how many files a single form submission may carry.

## Change post\_max\_size

### 1. Open Select PHP Version

Log in to your cPanel account, scroll to the **Software** section, and click **Select PHP Version**. If you cannot see it, type `PHP` into the search box at the top of the cPanel home page.

![The Select PHP Version icon in the Software section of the cPanel home page](/img/cP-CL-Select-PHP-Version-icon.gif)

### 2. Open the Options tab

Click **Options**. This tab lists the PHP directives you are allowed to change for the version currently selected on your account.

![The Options tab of the Select PHP Version page, listing editable PHP directives](/img/CL-options-menu.gif)

**Note:** if the **Options** tab shows an error mentioning the native PHP version, switch to a numbered (alt-php) version first. The **native** build is managed by the server, so the Selector cannot edit its directives. See [How to Change the PHP Version via CloudLinux Selector in cPanel](/cpanel/how-to-change-the-php-version-using-the-cloudlinux-selector-in-cpanel/).

### 3. Set post\_max\_size

Find **post\_max\_size** in the list, open the drop-down beside it, and choose the value you need. The change saves as soon as you select it and applies to new PHP requests immediately. There is no restart to perform and no confirmation button to press.

![The post_max_size drop-down open on the Options tab of the CloudLinux PHP Selector, showing the selectable sizes](/img/CL-post_max_size.gif)

### 4. Set upload\_max\_filesize in the same visit

While you are on the **Options** tab, check **upload\_max\_filesize** too. Changing only one of the pair is the single most common reason this procedure appears not to work. The next section explains how the two relate.

### 5. Confirm it took effect

Reload the page you were troubleshooting and retry the upload. If your application has a system information screen, read the value there rather than trusting the drop-down: WordPress shows it under **Tools** then **Site Health** then **Info** then **Server**, and most other platforms have an equivalent panel. That reading reports what PHP is genuinely enforcing.

## How post\_max\_size and upload\_max\_filesize Work Together

These two directives are not alternatives, and they do not do the same job. Getting the relationship right is most of the work.

- **`upload_max_filesize` caps each individual file.** One file larger than this figure is rejected, even if the request as a whole is small.
- **`post_max_size` caps the whole request.** Every file plus every form field plus the encoding overhead, added together.
- **The effective ceiling for a single-file upload is the lower of the two.** Setting `upload_max_filesize` to `256M` while `post_max_size` stays at `8M` gives you an 8 MB limit, not a 256 MB one. This is exactly why raising one alone changes nothing.
- **Always keep `post_max_size` comfortably larger than `upload_max_filesize`.** A useful rule of thumb is a few megabytes of headroom, or roughly a quarter more for forms that carry a lot of text. For a 64 MB file limit, `post_max_size` of `96M` or `128M` is a sensible pairing.
- **Multiple files in one submission are added together.** A gallery uploader sending six 20 MB images in a single request needs `post_max_size` above 120 MB, even though no single file comes near `upload_max_filesize`. Uploaders that send each file as its own separate request, as the WordPress media library does by default, do not have this problem.
- **The figure your application advertises is derived, not configured.** When a CMS displays a maximum upload size, it is normally reporting the lower of these two directives back to you. If that displayed number will not move, you have changed one of the pair and not the other.

## What Happens When a Request Exceeds post\_max\_size

This behaviour is the reason `post_max_size` problems are so much harder to diagnose than `upload_max_filesize` problems, and it is worth understanding before you start guessing at values.

When a request body is larger than `post_max_size`, PHP discards the *entire* body. `$_POST` and `$_FILES` both arrive empty. Your application is not told that a file was too large, because from its point of view nothing was submitted at all. Nothing is shown in the browser and no upload error code is set, so the only trace is usually a line in the PHP error log noting that the POST content length exceeded the limit. That log entry is the quickest way to confirm you are looking at this failure rather than another one.

The practical symptoms are distinctive once you know them:

- The form appears to submit, then simply reloads itself blank, with no message and no saved record.
- The file "vanishes" with no upload error shown anywhere.
- An AJAX uploader shows a generic HTTP error, or hangs at 100 per cent and never completes.
- Small files work perfectly and only large ones fail silently.

Contrast that with an over-large *single file* under `upload_max_filesize`: the request still arrives, `$_FILES` is populated, and the entry carries error code `1` (`UPLOAD_ERR_INI_SIZE`), which is why applications can show a tidy "file exceeds the maximum upload size" message in that case. **A clear error message points at `upload_max_filesize`. Silence points at `post_max_size`.**

## Choosing a Sensible Value

- **Start from the largest file you genuinely need to accept**, then add headroom for the rest of the form. Do not start from the largest figure the drop-down offers.
- **Raise in steps.** Move up one or two increments, retest with a real file, and stop when it works. Jumping to the maximum removes the diagnostic signal you were using.
- **Bigger is not free.** A very high limit lets a single request tie up a PHP worker, disk space in the temporary upload directory and account bandwidth for a long time. On a site with a public upload form it also widens the surface for abuse, so cap it at what your workload actually needs.
- **Do not choose `0` if the option appears.** Zero means no limit at all, which removes a genuinely useful safety valve.
- **Very large files are usually the wrong tool for a web form.** Multi-gigabyte transfers belong in FTP, SFTP or the cPanel File Manager rather than a browser upload, which has to survive the whole transfer inside one HTTP request.

## Things That Catch People Out

- **The value is stored per PHP version.** Each version keeps its own set of Options values. If you later change your PHP version, the new version starts on its own defaults and your tuned `post_max_size` does not follow it across. Re-check the Options tab immediately after any version change.
- **The setting is per account, not per domain, but only for domains that use the Selector.** Every domain, subdomain and add-on domain that follows the account's Selector PHP version shares the value. A domain pinned to its own PHP version in **MultiPHP Manager**, or running PHP-FPM, bypasses the Selector and keeps its own settings, which are changed in **MultiPHP INI Editor** instead. Where the Selector shows a **My domains** tab, it lists which domains the Selector governs.
- **`memory_limit` can undercut it.** Historically PHP expected `memory_limit` to be larger than `post_max_size`, which in turn is larger than `upload_max_filesize`. Modern PHP streams uploads to a temporary file rather than holding them in memory, so a large upload no longer requires a matching memory allowance by itself. What does still consume memory is whatever your application does with the file afterwards, such as resizing an image or parsing a spreadsheet. If large uploads arrive intact and then fail during processing, the constraint is memory, not this directive. See [How to Increase or Decrease PHP Memory Limit via CloudLinux Selector in cPanel](/cpanel/how-to-increase-or-decrease-php-memory-limit-via-cloudlinux-selector-in-cpanel/).
- **Time limits bite before size limits on slow connections.** A 200 MB upload over a modest domestic uplink can take several minutes. If `max_execution_time` or `max_input_time` expires first, the upload fails regardless of how generous `post_max_size` is. Both appear on the same **Options** tab.
- **Some applications impose their own cap on top.** Content management systems, form plugins and file manager plugins frequently carry a separate maximum of their own, set in their admin screens or in a configuration file. If PHP now allows 128 MB and the application still refuses at 32 MB, the remaining limit is in the application.
- **A custom `php.ini` or `.htaccess` entry may be doing nothing.** Under the PHP handlers used with the CloudLinux Selector, `php_value post_max_size` lines in `.htaccess` are typically ignored, and a stray `php.ini` in your web root may be ignored or may conflict with the Selector. Set the value in one place, in the Selector, and remove the leftovers.
- **`max_file_uploads` is a separate ceiling.** It limits how many files one request may contain, commonly 20. A bulk upload of 50 small files can fail on the count while sitting far below every size limit.
- **Command-line and cron runs are separate.** A script run through cron or PHP CLI does not necessarily inherit the same values as a web request. If a scheduled import behaves differently from the same task in the browser, that difference is the first thing to check.
- **The drop-down offers fixed choices, not free text.** If the exact figure you want is not listed, pick the next value up. If the option is greyed out or missing entirely, the value is locked at plan level, and only Noiz support can change it.

## Troubleshooting

- **Symptom: the upload form submits and returns to a blank or empty page, with nothing saved and no error.** This is the classic `post_max_size` failure. The whole POST body was discarded. Raise `post_max_size` above the total size of the request, not just the file.
- **Symptom: a clear "file is too large" message naming a size.** That is `upload_max_filesize` rejecting the individual file, and the message usually names the current limit. Raise that directive, then confirm `post_max_size` is still comfortably above it. See [How to Increase PHP's upload\_max\_filesize Value Using CloudLinux Selector in cPanel](/cpanel/how-to-increase-phps-upload-max-filesize-value-using-cloudlinux-selector-in-cpan/).
- **Symptom: the advertised maximum upload size in the application will not change.** You have raised one of the pair and not the other. The displayed figure is the lower of `post_max_size` and `upload_max_filesize`.
- **Symptom: the change saved but the site still reports the old value.** Confirm the account is on the PHP version you edited, not a different one, and clear any full-page or object cache in the application before re-reading the figure.
- **Symptom: the Options tab is empty or shows an error.** The account is on the **native** PHP build. Switch to a numbered version first, then return to Options.
- **Symptom: the upload runs for a while, then times out or drops near the end.** That is a time limit or a connection problem rather than a size limit. Check `max_execution_time` and `max_input_time`, and test the same file over a faster connection before raising sizes further.
- **Symptom: the file uploads, then the page errors or dies during processing.** The upload succeeded and the application ran out of memory or time handling it. Raise `memory_limit` rather than `post_max_size`.

## Related Guides

- [How to Increase PHP's upload\_max\_filesize Value Using CloudLinux Selector in cPanel](/cpanel/how-to-increase-phps-upload-max-filesize-value-using-cloudlinux-selector-in-cpan/)
- [How to Increase or Decrease PHP Memory Limit via CloudLinux Selector in cPanel](/cpanel/how-to-increase-or-decrease-php-memory-limit-via-cloudlinux-selector-in-cpanel/)
- [How to Change the PHP Version via CloudLinux Selector in cPanel](/cpanel/how-to-change-the-php-version-using-the-cloudlinux-selector-in-cpanel/)

If large uploads still fail after raising both directives, open a ticket with Noiz support. Include your domain name, the values you set, the size of the file you are uploading and the exact behaviour you see, including whether an error message appears at all. On managed plans, Noiz will identify which limit is actually being reached and tune it for you.

---
Source: https://docs.noiz.ie/cpanel/how-to-increase-phps-post-max-size-value-using-cloudlinux-selector-in-cpanel/