To compress files using 7-Zip, right-click the files, choose 7-Zip, then Add to archive, pick a format and a compression level, and click OK. That answer takes ten seconds, and it is also where most guides stop — which is a shame, because the choices in that dialog are the part that matters.
Compression is one of those tasks everyone does and almost nobody thinks about, right up until an archive will not open on the machine that needs it or a backup takes four hours because someone left the level on Ultra. The dialog has about six settings worth understanding, and there is a command line underneath it that turns this into something you can schedule.
Table of contents
- The dialog, setting by setting
- Choosing a format, and why it matters more than the level
- The command line, which is where this gets useful
- Compressing a site or a database for transfer
- What the server on the other end can do with it
- Encryption, and what it does not protect
- How this fits the rest of the stack
- FAQ
The dialog, setting by setting
Select your files, right-click, 7-Zip, Add to archive. The window that opens has more in it than the average user ever changes, and four of those settings genuinely matter.
- Archive format. 7z compresses best. zip opens everywhere. tar preserves Unix permissions but does not compress on its own.
- Compression level. Store does nothing, Normal is the sensible default, Ultra costs a great deal of time and memory for a few percent.
- Dictionary size. Larger dictionaries find matches further apart, which helps on big similar files and consumes a lot of RAM.
- Split to volumes. Breaks the archive into fixed-size parts, which is how you get a 4GB file past an upload limit.
The compression level is where people lose the most time. Going from Normal to Ultra on a large folder can take several times longer and typically saves single-digit percentages. For anything already compressed — JPEGs, MP4s, PDFs, existing zip files — it saves essentially nothing, because that data has no redundancy left to find. Compressing a folder of photos at Ultra is pure waiting.
Where high levels do pay off is text: source code, logs, SQL dumps, CSV exports. A database dump can compress to a small fraction of its original size because SQL is enormously repetitive. That is the case where waiting is worth it.
Choosing a format, and why it matters more than the level
The 7z format is genuinely better at compression than zip, usually by a noticeable margin on text. It also supports strong AES-256 encryption including encrypted filenames, and solid compression, where files are treated as one continuous stream so similarities between them can be exploited.
It also requires 7-Zip, or a compatible tool, at the other end. That is fine on your own machine and a real problem when the other end is a shared host with a control panel that only knows zip, a colleague on a Mac with no extra software installed, or a web application that unpacks uploads server-side.
So the rule is about the destination, not the ratio. If you control both ends, use 7z. If you are sending it to someone else or uploading it somewhere that will unpack it for you, use zip and accept the larger file. An archive nobody can open has a compression ratio of zero.
One caveat with solid archives: because files share a compressed stream, extracting a single file from the middle requires decompressing everything before it. For an archive you will unpack whole, that is irrelevant. For an archive you will pick individual files out of, turn solid mode off.
The command line, which is where this gets useful
The GUI is fine for one-off jobs. The moment you want this to happen on a schedule, or as part of a script, the 7z command is what you need. On Windows it is 7z.exe in the install directory; on Linux the package is usually p7zip or 7zip.
# Create an archive
7z a backup.7z ./site-files/
# Maximum compression
7z a -mx=9 dump.7z database-dump.sql
# Store only, no compression (fast, for already-compressed data)
7z a -mx=0 media.7z ./videos/
# Encrypt contents and filenames, prompting for the password
7z a -p -mhe=on private.7z ./documents/
# Split into 100MB volumes
7z a -v100m large.7z ./bigfolder/
# Extract, keeping the directory structure
7z x archive.7z -o./restored/
# List contents without extracting
7z l archive.7z
# Test integrity
7z t archive.7zTwo flags to be careful with. Use x rather than e to extract — e flattens everything into one directory, which is rarely what you want and occasionally destructive if filenames collide. And never put a password directly after -p on a shared machine, because the command lands in your shell history; -p on its own prompts for it.
Compressing a site or a database for transfer
The common real task behind this search is packaging a website or a database export to move it somewhere. A few things make that go better.
Exclude what you do not need before compressing. A node_modules directory, a .git folder, a cache directory, and a logs folder can easily be most of the size and none of the value. The -xr! switch excludes recursively:
7z a site.7z ./public_html/ -xr!node_modules -xr!.git -xr!*.log -xr!cacheCompress the database separately from the files. They restore separately, they change at different rates, and mixing them means a schema-only restore requires unpacking gigabytes of images.
Check for hidden files. A .env, a .htaccess, or a .user.ini can be the one file the destination genuinely needs, and file managers hide them by default. Archiving from the command line avoids this entirely.
Then verify before you delete anything. 7z t on the finished archive takes seconds and catches a truncated or corrupted file while the original still exists. A backup you have never tested is a hope, not a backup.
What the server on the other end can do with it
If you are uploading an archive to a host, the question is what that host can unpack. Many control panels include a file manager that handles zip and often tar.gz, and fewer handle 7z. If the host offers SSH you can install and run 7z yourself; if it does not, you are limited to what the panel supports.
This is where the format choice stops being academic. Producing a beautifully compressed 7z and then discovering the destination cannot open it means doing the whole job twice over a slow connection.
For Linux destinations, tar.gz remains the safest default. It is universally supported, it preserves Unix permissions and symlinks — which zip handles poorly and 7z handles inconsistently — and every server has the tools to unpack it already:
tar -czf site.tar.gz ./public_html/
tar -xzf site.tar.gz -C /var/www/Managed WordPress on RunxBuild includes a file manager in the dashboard that browses, uploads, and unzips, so a packaged site can go up and be unpacked without SFTP credentials or a terminal. That is the case this whole workflow is usually serving.
Encryption, and what it does not protect
7-Zip’s AES-256 encryption on the 7z format is strong and worth using for anything sensitive leaving your machine. With -mhe=on the filenames are encrypted too, which matters more than people expect — a list of filenames often reveals as much as the contents.
The zip format’s encryption is weaker and its implementations vary, so if the contents genuinely need protecting, use 7z and accept the compatibility cost.
What encryption does not do is protect you from a weak password or from sending the password through the same channel as the file. Emailing an encrypted archive and then emailing the password achieves close to nothing. And an encrypted archive whose password lives only in someone’s head is a data-loss event waiting for that person to change jobs.
How this fits the rest of the stack
Compressing a site into an archive and moving it by hand is a workflow that makes sense exactly once. If you find yourself doing it every release, the archive is standing in for a deploy pipeline, and the version that builds from a commit and keeps the previous release around is less work overall. The RunxBuild hosting calculator shows what a hosted site with builds, storage, and bandwidth comes to, which is the fair comparison against an afternoon of zipping and uploading.
Useful related references:
- tar Command in Linux: Create, Extract, List, Compress Archives
- PHP Composer: Dependency Management, and the Two Files That Matter
- Secure WordPress Media Files: The Uploads Folder Is Public
- Services on RunxBuild
FAQ
Is 7z better than zip?
For compression ratio and encryption strength, yes, usually by a clear margin on text. For compatibility, no — zip opens on any machine and any control panel without extra software. Choose by destination: 7z when you control both ends, zip when someone or something else has to open it.
What is the best 7-Zip compression setting?
Normal for almost everything. Ultra costs several times the processing time for a few percent of size, and gives near zero benefit on already-compressed data like photos, video, or PDFs. Save Ultra for large text: source code, logs, and SQL dumps, where the extra effort actually pays.
How do I compress a folder using the 7-Zip command line?
Use 7z a archive.7z ./folder/ to create it, adding -mx=9 for maximum compression or -mx=0 for none. Exclude noise with -xr!node_modules and similar. Extract with 7z x to preserve the directory structure, not 7z e, which flattens everything into one directory.
Can a web server unzip a 7z file?
Only if 7-Zip or p7zip is installed on it, which is not a given. Most hosting control panel file managers handle zip and often tar.gz, and fewer handle 7z. If the destination is a Linux server, tar.gz is the safest choice because it preserves permissions and symlinks and every system can already read it.
Is 7-Zip password protection secure?
The AES-256 encryption on the 7z format is strong, and -mhe=on also encrypts the filenames, which is worth enabling. The zip format’s encryption is considerably weaker. In practice the weak point is rarely the algorithm — it is a short password, or sending the password through the same email as the file.