This list includes the core php.ini directives you can set to
configure your PHP setup. Directives handled by extensions are listed
and detailed at the extension documentation pages respectively;
Information on the session directives for example can be found at the
sessions page.
Note:
The defaults listed here are used when php.ini is not loaded; the values for the production and development php.ini may vary.
Tells PHP whether the short form (<? ?>)
of PHP's open tag should be allowed. If you want to use PHP in
combination with XML, you can disable this option in order to
use <?xml ?> inline. Otherwise, you
can print it with PHP, for example: <?php echo '<?xml
version="1.0"?>'; ?>. Also, if disabled, you must use the
long form of the PHP open tag (<?php ?>).
Note:
This directive does not affect the shorthand
<?=, which is always available.
The number of significant digits stored while serializing floating point numbers.
-1 means that an enhanced algorithm for rounding
such numbers will be used.
This directive allows certain functions to be disabled.
It takes a comma-delimited list of function names.
As of PHP 8.0.0, disabling a function removes its definition,
allowing userland to redefine it.
Prior to PHP 8.0.0, disabling a function just prevented the function
from being invoked.
This directive allows certain classes to be disabled.
It takes a comma-delimited list of class names.
Disabling a class just prevents the class's instantiation.
Only internal classes can be disabled using this directive.
User-defined classes are unaffected.
This directive must be set in php.ini.
It cannot be set in httpd.conf.
Warning
This directive can be circumvented and should not be considered a
sufficient security measure for shared hosting environments.
When set to 1, assertion code will be generated and
executed (development mode). When set to 0,
assertion code will be generated but it will be skipped (not executed)
at runtime. When set to -1, assertion code will not
be generated, making the assertions zero-cost (production mode).
Note:
If a process is started in production mode, zend.assertions
cannot be changed at runtime, since the code for assertions was not generated.
If a process is started in development mode, zend.assertions
cannot be set to -1 at runtime.
When the timeout set in max_execution_time
has been hit, the PHP runtime will tear down resources gracefully. If
something gets stuck while this happens, the hard timeout will tick
for the set amount of seconds. When the hard timeout is hit, PHP will
exit ungracefully. When set to 0, the hard timeout will never activate.
When PHP stops from a hard timeout, it will look something like this:
Fatal error: Maximum execution time of 30+2 seconds exceeded (terminated) in Unknown on line 0
Enables parsing of source files in multibyte encodings. Enabling zend.multibyte
is required to use character encodings like SJIS, BIG5, etc that contain special
characters in multibyte string data. ISO-8859-1 compatible encodings like UTF-8,
EUC, etc do not require this option.
Enabling zend.multibyte requires the mbstring extension to be available.
This value will be used unless a
declare(encoding=...)
directive appears at the top of the script. When ISO-8859-1 incompatible encoding
is used, both zend.multibyte and zend.script_encoding must be used.
Literal strings will be transliterated from zend.script_encoding to
mbstring.internal_encoding, as if
mb_convert_encoding() would have been called.
Check for BOM (Byte Order Mark) and see if the file contains valid
multibyte characters.
This detection is performed before processing of
__halt_compiler().
Available only in Zend Multibyte mode.
This is an Apache1 mod_php-only directive that forces an Apache child to exit if a PHP execution timeout occurred.
Such a timeout causes an internal longjmp() call in Apache1 which can leave some extensions in an inconsistent
state. By terminating the process any outstanding locks or memory will be cleaned up.
This sets the maximum amount of memory in bytes that a script
is allowed to allocate. This helps prevent poorly written
scripts for eating up all available memory on a server. Note that
to have no memory limit, set this directive to -1.
As of PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, this is a soft limit:
an allocation that crosses it is, in most cases, allowed to complete
before the fatal error is raised, so the memory usage of a process may
briefly exceed memory_limit. A separate hard limit,
controlled by
memory_hard_limit_percent,
bounds how far it may be exceeded.
When an int is used, the
value is measured in bytes. Shorthand notation, as described
in this FAQ, may also be used.
Available as of PHP 8.5.0. This startup-only setting controls the
maximum value that memory_limit
may be configured to, either at startup or at runtime (e.g. via
ini_set()). Setting
memory_limit to a value
exceeding max_memory_limit results in a
warning and the value being capped. Set to -1
(the default) to impose no upper bound.
When an int is used, the
value is measured in bytes. Shorthand notation, as described
in this FAQ, may also be used.
Available as of PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Sets a hard
memory limit, expressed as a percentage of
memory_limit.
For example, with memory_limit=128M and
memory_hard_limit_percent=150, the hard limit is
192M. Unlike
memory_limit, the hard limit
can never be exceeded.
Warning
This directive was introduced in the security releases of
21 October 2026, which fix two critical vulnerabilities
(CVE-2026-109618, CVE-2026-109619) that can allow unauthenticated
remote code execution, one of them triggered through out-of-memory
handling. If this directive is not recognized, the PHP version in
use is affected by these vulnerabilities and must be updated
immediately. See the
» security advisory
for details.
When an allocation exceeds memory_limit
(the soft limit), the memory is still allocated, and the usual
fatal error is raised once the engine reaches a safe point.
Shutdown functions registered with
register_shutdown_function() still run.
When an allocation would exceed the hard limit, the process is
terminated immediately with exit status 137.
A message is written directly to the standard error stream, looking
something like this:
Hard memory limit of 201326592 bytes exhausted
The message does not go through the error handling mechanism, so it
is not passed to error handlers or written to the
error_log. No further PHP code
runs: shutdown functions, destructors and output buffer handlers are
all skipped.
The value must be 100 or greater, or
-1.
When unset (the default) or set to -1, the hard
limit is twice memory_limit
if memory_limit is
1G or less, and
memory_limit plus
1G otherwise. For example, with the default
memory_limit=128M, the hard limit is
256M, and with memory_limit=4G
it is 5G. If
memory_limit is set to
-1, there is no hard limit either.
Caution
A value of 100 makes the hard limit equal to
memory_limit, which turns
most out-of-memory conditions into an immediate termination of the
process instead of a fatal error. Shutdown-time work such as
logging, releasing locks or finishing a response will then never
run on out-of-memory.
Note:
Because the process exits without producing output, in
multi-request environments such as PHP-FPM the worker serving the
request is terminated and the client receives no response from
PHP; the process manager starts a replacement worker. Exit status
137 is also the status reported for a process
killed by SIGKILL, for example by the kernel
OOM killer or a container runtime, so check the standard error
stream to tell the cases apart.
Determines the size of the realpath cache to be used by PHP. This
value should be increased on systems where PHP opens many files, to
reflect the quantity of the file operations performed.
The size represents the total number of bytes in the path strings
stored, plus the size of the data associated with the cache entry. This
means that in order to store longer paths in the cache, the cache size
must be larger. This value does not directly control the number of
distinct paths that can be cached.
The size required for the cache entry data is system dependent.
Duration of time (in seconds) for which to cache realpath information
for a given file or directory. For systems with rarely changing files,
consider increasing the value.
Sets the order of the EGPCS (Environment,
Get, Post,
Cookie, and Server) variable
parsing. For example, if variables_order
is set to "SP" then PHP will create the
superglobals$_SERVER and
$_POST, but not create
$_ENV, $_GET, and
$_COOKIE. Setting to "" means no
superglobals will be set.
Warning
In both the CGI and FastCGI SAPIs,
$_SERVER is
also populated by values from the environment; S
is always equivalent to ES regardless of the
placement of E elsewhere in this directive.
Note:
The content and order of
$_REQUEST is also
affected by this directive.
This directive describes the order in which PHP registers GET, POST
and Cookie variables into the _REQUEST array. Registration is done
from left to right, newer values override older values.
When enabled, the SERVER, REQUEST, and ENV variables are created when they're
first used (Just In Time) instead of when the script starts. If these
variables are not used within a script, having this directive on will
result in a performance gain.
Warning
Usage of SERVER, REQUEST, and ENV variables is checked during the compile time
so using them through e.g. variable variables will
not cause their initialization.
This feature has been
DEPRECATED as of PHP 8.5.0. Relying on this feature
is highly discouraged.
Note:
Deriving $_SERVER['argc'] and $_SERVER['argv']
from the query string for non-CLI SAPIs has been deprecated.
Configure register_argc_argv=0 and switch to either
$_GET or $_SERVER['QUERY_STRING']
to access the information, after verifying that the usage is safe.
Disabling this option causes $_POST and
$_FILESnot to be populated. The
request body remains unconsumed in
php://input and can be read manually
or parsed via request_parse_body().
This can be useful to proxy requests or to process the POST data in a
memory efficient fashion.
Sets max size of post data allowed. This setting also affects
file upload. To upload large files, this value must be larger
than upload_max_filesize.
Generally speaking,
memory_limit should be
larger than post_max_size.
When an int is used, the
value is measured in bytes. Shorthand notation, as described
in this FAQ, may also be used.
If the size of post data is greater than post_max_size, the
$_POST and $_FILESsuperglobals
are empty. This can be tracked in various ways, e.g. by passing the
$_GET variable to the script processing the data,
i.e. <form action="edit.php?processed=1">,
and then checking if $_GET['processed'] is set.
Note:
PHP allows shortcuts for byte values, including K (kilo), M (mega)
and G (giga). PHP will do the conversions automatically if you
use any of these. Be careful not to exceed the 32 bit signed integer
limit (if you're using 32bit versions) as it will cause your script
to fail.
Changelog for post_max_size
Version
Description
5.3.4
post_max_size = 0 will not disable the limit when the content
type is application/x-www-form-urlencoded or is not registered with PHP.
5.3.2 , 5.2.12
Allow unlimited post size by setting post_max_size to 0.
Specifies the name of a file that is automatically parsed
before the main file. The file is included as if it was
called with the require function, so
include_path is used.
Specifies the name of a file that is automatically parsed
after the main file. The file is included as if it was
called with the require function, so
include_path is used.
The special value none
disables auto-appending.
Note:
If the script is terminated with exit(),
auto-append will not occur.
All versions of PHP will use this value as the charset within the
default Content-Type header sent by PHP if the header isn't overridden
by a call to header().
Setting default_charset to an empty value is
not recommended.
Specifies a list of directories where the
require, include,
fopen(), file(),
readfile() and file_get_contents()
functions look for files. The format is like the system's
PATH environment variable: a list of directories
separated with a colon in Unix or semicolon in Windows.
PHP considers each entry in the include path separately when looking for
files to include. It will check the first path, and if it doesn't find
it, check the next path, until it either locates the included file or
returns with an
E_WARNING
or an E_ERROR.
You may modify or set your include path at runtime using
set_include_path().
Example #1 Unix include_path
include_path=".:/php/includes"
Example #2 Windows include_path
include_path=".;c:\php\includes"
Using a . in the include path allows for
relative includes as it means the current directory. However,
it is more efficient to explicitly use include
'./file' than having PHP always check the current
directory for every include.
Note:
ENV variables are also accessible in .ini files.
As such it is possible to reference the home directory using
${LOGIN} and ${USER}.
Environment variables may vary between Server APIs as those environments
may be different.
Example #3 Unix include_path using ${USER} env variable
Limit the files that can be accessed by PHP to the specified
directory-tree, including the file itself.
When a script tries to access the filesystem, for example using
include, or fopen(), the location of the file
is checked.
When the file is outside the specified directory-tree, PHP will refuse to access it.
All symbolic links are resolved, so it's not possible to avoid this restriction
with a symlink. If the file doesn't exist then the symlink couldn't be
resolved and the filename is compared to (a resolved) open_basedir.
open_basedir can affect more than just filesystem functions; for example
if MySQL is configured to use mysqlnd drivers,
LOAD DATA INFILE will be affected by open_basedir.
Much of the extended functionality of PHP uses open_basedir in this way.
The special value .
indicates that the working directory of the script will be used as the
base-directory. This is, however, a little dangerous as the working directory
of the script can easily be changed with chdir().
In httpd.conf, open_basedir can be turned off
(e.g. for some virtual hosts)
the same way as
any other configuration directive with "php_admin_value open_basedir
none".
Under Windows, separate the directories with a semicolon. On all
other systems, separate the directories with a colon. As an Apache
module, open_basedir paths from parent directories are now
automatically inherited.
The restriction specified with open_basedir is a
directory name, not a prefix.
The default is to allow all files to be opened.
Note:
open_basedir can be tightened at run-time. This means
that if open_basedir is set to /www/ in php.ini
a script can tighten the configuration to
/www/tmp/ at run-time with
ini_set(). When listing several directories, you
can use the PATH_SEPARATOR constant as a separator
regardless of the operating system.
As of PHP 8.3.0, open_basedir no longer accepts a
paths containing the parent directory (..) when
set at runtime using ini_set().
Note:
Using open_basedir will set realpath_cache_size
to 0 and thus disable the realpath cache.
Warning
open_basedir does not restrict access to Unix domain sockets.
PHP socket functions such as stream_socket_client() and
fsockopen() can connect to a Unix socket path
(e.g. unix:///var/run/docker.sock)
regardless of the open_basedir setting.
Caution
open_basedir is just an extra safety net, that is in no way
comprehensive, and can therefore not be relied upon when security is needed.
PHP's "root directory" on the server. Only used if
non-empty.
If PHP was not compiled with FORCE_REDIRECT, you should
set doc_root if you are running PHP as a CGI under any web
server (other than IIS). The alternative is to use the
cgi.force_redirect configuration below.
Controls whether CGI PHP checks for line starting
with #! (shebang) at the top of the running script.
This line might be needed if the script support running both as
stand-alone script and via PHP CGI. PHP in
CGI mode skips this line and ignores its content if
this directive is turned on.
Provides realPATH_INFO/
PATH_TRANSLATED support for CGI.
PHP's previous behaviour was to set PATH_TRANSLATED
to SCRIPT_FILENAME, and to not grok what
PATH_INFO is. For more information on
PATH_INFO, see the CGI specs.
Setting this to 1 will cause PHP
CGI to fix its paths to conform to the spec. A
setting of zero causes PHP to behave as before. It is turned on by
default. You should fix your scripts to use
SCRIPT_FILENAME rather than
PATH_TRANSLATED.
cgi.force_redirect is necessary to provide security running PHP as a
CGI under most web servers. Left undefined, PHP
turns this on by default. You can turn it off at your own
risk.
Note:
Windows Users: When using IIS this option must
be turned off. For OmniHTTPD or Xitami the same applies.
If cgi.force_redirect is turned on, and you are not running under
Apache or Netscape (iPlanet) web servers, you may
need to set an environment variable name that PHP will look for to
know it is OK to continue execution.
Note:
Setting this variable may cause security issues,
know what you are doing first.
Tells PHP what type of headers to use when sending HTTP response
code. If it is disabled, PHP sends a » RFC 3875
"Status:" header that is supported by Apache and other web servers. When this option
is enabled, PHP will send » RFC 2616 compliant
headers.
If this option is enabled, and you are running PHP in a CGI environment (e.g. PHP-FPM)
you should not use standard RFC 2616 style HTTP status response headers, you should
instead use their RFC 3875 equivalent e.g. instead of header("HTTP/1.0 404 Not found");
you should use header("Status: 404 Not Found");
Leave it disabled unless you know what you're doing.
FastCGI under IIS (on WINNT based OS) supports the ability to impersonate
security tokens of the calling client. This allows IIS to define the
security context that the request runs under. mod_fastcgi under Apache
does not currently support this feature (03/17/2002).
Enable if running under IIS. Default is disabled.
The temporary directory used for storing files when doing
file upload. Must be writable by whatever user PHP
is running as. If not specified PHP will use the system's default.
If the directory specified here is not writable, PHP falls back to
the system default temporary directory. If
open_basedir is on, then
the system default directory must be allowed for an upload to
succeed.
If turned on, database connection functions that specify default values
will use those values in place of any user-supplied arguments. For details
on the default values, see the documentation for the relevant connection
functions.