Como Aumentar o Tamanho Máximo de Upload de Arquivo no WordPress

Você arrasta um vídeo de 60MB para a biblioteca de mídia do WordPress, espera alguns segundos e recebe de volta uma de três mensagens de erro: "The uploaded file exceeds the upload_max_filesize directive in php.ini", "413 Request Entity Too Large", ou simplesmente "HTTP error" sem mais explicação. A correção é quase sempre aumentar o tamanho máximo de upload, mas como na maioria dos tópicos de limites do WordPress, não há apenas um limite. Há quatro, eles vivem em lugares diferentes, e o mais baixo vence. Este guia explica qual limite causa qual mensagem de erro e como aumentar cada um nas várias configurações de host.

Qual limite é responsável por qual erro?

Quatro configurações separadas podem bloquear um upload. Saber qual delas o atingiu economiza muita tentativa e erro.

upload_max_filesize do PHP. O teto rígido sobre o tamanho de um único arquivo enviado. Padrão na maioria dos hosts é 2M a 64M. Se seu arquivo excede isso, o WordPress mostra a mensagem explícita "uploaded file exceeds the upload_max_filesize directive".
post_max_size do PHP. O tamanho máximo da requisição POST inteira, incluindo o arquivo mais quaisquer outros campos do formulário. Tem que ser pelo menos tão grande quanto upload_max_filesize; caso contrário, o upload falha silenciosamente antes mesmo do WordPress ver. O padrão é tipicamente 8M a 64M.
max_execution_time e max_input_time do PHP. Limites de tempo em segundos. Um upload grande sobre uma conexão lenta pode atingir o limite de tempo antes que o arquivo termine de transferir, mesmo se os limites de tamanho estiverem bem. O padrão geralmente é 30 a 60 segundos. Sintoma: o upload começa, a barra de progresso chega a 80%, depois falha com "HTTP error".
Limite do corpo da requisição do servidor web. O nginx tem uma diretiva client_max_body_size (padrão 1M, dolorosamente baixo para uploads de mídia). O Apache raramente limita isso por padrão, mas proxies reversos, balanceadores de carga e CDNs (Cloudflare, em particular, tem um limite de 100M em planos gratuitos, 200M no Pro, 500M no Business) todos aplicam seus próprios tetos. Sintoma: uma página "413 Request Entity Too Large" que não se parece com WordPress, porque o WordPress nunca recebeu a requisição.

O tamanho máximo real de upload é o mais baixo dos quatro. O WordPress mostra o limite efetivo na própria página de upload: abra Mídia, Adicionar Nova no admin e procure pela pequena linha "Tamanho máximo de upload" abaixo da área de upload.

Quanto você realmente precisa?

Um modelo mental prático:

32M. Suficiente para imagens típicas, PDFs e arquivos de áudio pequenos. O padrão em hosts compartilhados conservadores.
64M. Confortável para a maioria dos sites editoriais. Lida com rajadas de fotos de uma câmera moderna, PDFs maiores e clipes de vídeo curtos.
128M a 256M. A faixa certa para sites que regularmente enviam vídeo, arquivos PSD grandes, recursos de design ou arquivos zip de tema e plugin para uma instalação autogerenciada.
Acima de 256M. Principalmente relevante para sites pesados em vídeo, feeds de podcast com arquivos de áudio grandes, ou plataformas de curso com material de aula baixável. Vale a pena pensar se o arquivo realmente precisa viver no servidor WordPress, ou se um serviço como Vimeo, YouTube, Bunny Stream ou um bucket S3 dedicado é a melhor opção. O WordPress não é otimizado para servir arquivos de mídia grandes em escala.

Um detalhe que as pessoas perdem: o WordPress também tem seu próprio limite interno. Por padrão, ele não impõe um limite de tamanho além do que o PHP permite, então na maioria dos hosts as configurações do PHP são a única coisa em jogo. O filtro upload_size_limit existe se você quer definir um teto específico do projeto (útil em multisite para dar a diferentes papéis diferentes limites), mas só pode abaixar o limite efetivo, nunca elevá-lo além do PHP.

Opção 1: Aumentar limites do PHP via painel do seu host

Quase sempre o ponto certo de partida. A maioria dos hosts em 2026 expõe as configurações relevantes em seu painel, e as alterações têm efeito em segundos.

cPanel (IONOS, Hostinger, muitos revendedores)

Vá para MultiPHP INI Editor, selecione seu domínio e ajuste:

upload_max_filesize para seu valor alvo (ex.: 128M)
post_max_size para o mesmo valor ou superior (ex.: 128M)
max_execution_time para pelo menos 300 segundos para arquivos grandes
max_input_time para o mesmo valor
memory_limit para 256M ou superior (uploads carregam brevemente na memória durante o processamento)

Salve. A alteração entra em vigor imediatamente.

Plesk (All Inkl, DomainFactory, muitos hosts alemães)

Abra o domínio no Plesk, clique em PHP Settings, role até "Performance and security settings". Os campos são os mesmos do cPanel. Salve e os valores se aplicam na próxima requisição.

Hospedagem WordPress gerenciada (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Esses hosts quase sempre vêm com padrões sensatos já (tipicamente 64M a 128M). Se o limite ainda é muito baixo para seu caso de uso, o painel geralmente tem um slider ou campo de entrada. Alguns hosts (WP Engine, Pressable) limitam o máximo absoluto e exigem um ticket de suporte além de um certo tamanho, geralmente porque seu pipeline de upload pré-valida arquivos contra um CDN. Esses tickets são respondidos em horas, não dias.

Opção 2: .user.ini na raiz do WordPress

Se seu host roda PHP via FastCGI ou PHP FPM (que é essencialmente todo host moderno), mas não expõe um painel de configurações, você pode colocar um arquivo .user.ini diretamente no diretório raiz do WordPress:

upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

O PHP capta .user.ini automaticamente. A única peculiaridade é um tempo de cache padrão de cinco minutos (controlado pela configuração user_ini.cache_ttl), então as alterações nem sempre têm efeito na próxima requisição.

Verifique com a página Saúde do Site do WordPress: Ferramentas, Saúde do Site, Info, Servidor mostra o upload_max_filesize e post_max_size ativos. Se os valores ainda correspondem aos padrões antigos após dez minutos, o host ou desabilita o suporte a .user.ini ou roda o PHP em um modo que o ignora. Continue com a Opção 3.

Opção 3: php.ini em um servidor autogerenciado

Em um VPS ou servidor dedicado onde você controla o PHP diretamente, edite o php.ini ativo. Encontre-o com php --ini na linha de comando. O caminho varia conforme distribuição e versão do PHP (tipicamente /etc/php/8.2/fpm/php.ini em Debian ou Ubuntu, /etc/php.ini em CentOS ou RHEL).

Ajuste os mesmos cinco valores da Opção 1, depois recarregue o PHP FPM:

sudo systemctl reload php8.2-fpm

(Ajuste o número da versão para corresponder à sua instalação.) No Apache com mod_php, reinicie o Apache em vez disso. A alteração se aplica imediatamente, sem ação adicional necessária.

Opção 4: client_max_body_size do nginx

Esta é a que pega muita gente em nginx autogerenciado. O PHP pode ser configurado para aceitar uploads de 1GB, mas se o nginx ainda está limitado a 1M (o padrão), o upload nunca chega ao PHP. O navegador mostra um erro genérico "413 Request Entity Too Large", frequentemente sem qualquer indicação de que o nginx é o responsável.

Adicione a diretiva ao bloco server do seu site, ou globalmente no bloco http de nginx.conf:

client_max_body_size 128M;

Recarregue o nginx com sudo nginx -t && sudo systemctl reload nginx. O valor deve corresponder ou exceder seu post_max_size do PHP. Não há mal em defini-lo um pouco mais alto; o limite real ainda é o PHP.

Opção 5: Apache com .htaccess (legado)

Em configurações Apache mais antigas rodando mod_php (raro em hospedagem moderna, comum em servidores legados), você pode colocar as diretivas do PHP diretamente em .htaccess na raiz do WordPress:

php_value upload_max_filesize 128M
php_value post_max_size 128M
php_value max_execution_time 300
php_value max_input_time 300
php_value memory_limit 256M

Se seu host roda PHP via FastCGI ou PHP FPM (que é essencialmente todo host moderno), essa diretiva lança um erro 500 ou é silenciosamente ignorada. Use .user.ini da Opção 2 em vez disso.

Opção 6: Quando o limite está na camada CDN ou proxy

Se você configurou o PHP e o servidor web para permitir uploads de 256M, mas o upload ainda falha em, digamos, 100M, o gargalo está em algum lugar à frente do servidor WordPress. Culpados comuns:

Cloudflare limita o tamanho do corpo por plano: 100M no Free, 200M no Pro, 500M no Business, 500M no Enterprise (aumentado mediante solicitação). Para uploads maiores, ou atualize o plano, exclua o admin do WordPress do proxy definindo o registro DNS como "DNS only" para /wp-admin/ via uma Page Rule, ou use um subdomínio direto que contorne o Cloudflare para uploads.
Cloudways tem uma camada varnish que tem como padrão um limite baixo de tamanho de corpo. O painel deles expõe a configuração em "Application Settings, Server Configurations".
Proxies reversos configurados na frente do nginx (HAProxy, Traefik) todos têm seus próprios limites de tamanho de corpo que precisam ser aumentados em seus respectivos arquivos de configuração.
Alguns firewalls e plugins de segurança na camada WAF (Sucuri, Wordfence Premium com WAF na nuvem) limitam tamanhos de upload por padrão. O painel de configurações deles tem uma opção separada para isso.

O truque de diagnóstico: tente o upload de dentro do próprio servidor usando curl com um arquivo local. Se o upload funciona localmente mas falha pela URL pública, o limite está em uma camada de proxy ou CDN, não no PHP.

Como verificar que os novos limites estão ativos

Abra Ferramentas, Saúde do Site, Info no admin do WordPress.
Expanda a seção Servidor. Procure por upload_max_filesize, post_max_size, max_execution_time e memory_limit. Todos devem refletir os novos valores.
Para uma verificação mais rápida, abra Mídia, Adicionar Nova. A linha "Tamanho máximo de upload" na parte inferior da área de upload deve mostrar o novo limite efetivo.
Tente o upload real que disparou o problema. Se ainda falhar, anote exatamente qual mensagem de erro você recebe; isso aponta para qual dos quatro limites ainda é muito baixo.

O que fazer quando o arquivo é genuinamente grande demais para upload HTTP

Acima de 500M a 1GB, uploads pelo navegador deixam de ser práticos independentemente das configurações do servidor. A conexão TCP fica instável, proxies intermediários expiram, e um único soluço de rede significa começar de novo. Duas alternativas mais sensatas:

Envie via SFTP e importe pelo WordPress. Coloque o arquivo diretamente em wp-content/uploads/ANO/MES/ via SFTP, depois use um plugin como Add From Server ou Media Sync para registrá-lo na biblioteca de mídia. O WordPress gera os metadados e miniaturas como se você tivesse enviado normalmente.
Serviços externos de mídia. Para vídeo especificamente, Vimeo, Bunny Stream, Cloudflare Stream e YouTube todos lidam com hospedagem e streaming adaptativo muito melhor do que o núcleo do WordPress. A maioria dos temas e construtores de página modernos os incorpora nativamente, incluindo miniaturas auto geradas. Mesma lógica para áudio (Soundcloud, Spotify para podcasters) e downloads de arquivos grandes (S3 com um CloudFront ou Bunny CDN na frente).

Hospedar um vídeo bruto de 5GB em hospedagem WordPress compartilhada e servi-lo diretamente é tecnicamente possível, mas raramente o movimento certo. Os custos de largura de banda, a falta de bitrate adaptativo e a tensão em um único worker PHP por espectador simultâneo todos apontam para hospedagem de mídia dedicada.

Erros comuns a evitar

Aumentar upload_max_filesize sem aumentar post_max_size junto. O upload falha silenciosamente porque a requisição POST inteira excede o menor dos dois. Sempre altere-os juntos.
Definir valores absurdamente altos "por precaução". Um limite de upload de 4G em um servidor com 4GB de RAM total é um vetor de negação de serviço. O PHP carrega partes do upload na memória durante o processamento. Escolha um valor que reflita o que você realmente envia, mais uma folga.
Esquecer max_execution_time. Um upload de 500MB em uma conexão de 10 Mbit/s leva cerca de sete minutos. Se max_execution_time é o padrão de 30 segundos, a requisição é morta no meio do upload independentemente dos limites de tamanho.
Editar o php.ini errado. Um erro comum em sistemas com múltiplas versões do PHP instaladas (ex.: 7.4 e 8.2 ambas presentes, mas apenas uma ativa). O comando php --ini na linha de comando pode apontar para um php.ini diferente do que o PHP FPM usa para o servidor web. Saúde do Site é a fonte autoritativa.

Para a maioria dos casos, dois minutos no painel do host aumentando cinco valores para padrões sensatos resolve o problema permanentemente. As mensagens de erro em torno dos limites de tamanho de upload são infelizmente formuladas para soarem como questões técnicas obscuras, mas a correção real é mecânica e bem documentada. Uma vez que os limites são dimensionados para sua carga de trabalho real, este é um dos tópicos do WordPress que não precisa voltar à tona.