Uploading files to the server is one of the first things you need to learn when you have a site, and also one of the most confusing. There are three possible routes, they look fairly similar from the outside, and yet they differ significantly in security, convenience, and what you can actually do with each.
The panel file manager
This is the option you already have, with nothing to install. Every modern control panel includes a file browser in the browser: you see folders, upload, download, edit text files, change permissions and extract archives.
When it fits: for one-off changes. Editing a configuration line, uploading a single file, checking whether something is where it should be, changing folder permissions. For that it is the fastest route, because nothing needs configuring.
It also has one concrete advantage people underrate: it can extract archives on the server. Uploading a 40-megabyte compressed file and extracting it there is vastly faster than uploading five thousand loose files, because every individual file involves a complete network negotiation.
When it does not fit: for moving many files, for daily work, or when the connection is unstable, since an interrupted browser upload usually starts over from zero.
FTP: the veteran you should no longer use
FTP is the classic file transfer protocol. It has existed since the seventies and works everywhere.
And it has a serious problem: it transmits everything in plain text. Your username, your password and the file contents travel unencrypted. Anyone able to observe the network between your computer and the server can read those credentials as-is.
This is not theoretical. It is one of the most common ways sites get compromised: someone connects over FTP from a coffee shop wifi, an attacker on the same network captures the password, and a week later the site has malicious code injected into every PHP file.
There is a variant called FTPS that adds encryption to traditional FTP and solves the problem. It is a valid option, but configuration is sometimes awkward because of the ports it needs.
SFTP: what you should be using
Despite the similar name, SFTP is not FTP with encryption: it is a different protocol, travelling inside a secure connection of the same kind used to administer servers from the command line.
Everything is encrypted: credentials, commands and content. It uses a single port, which massively simplifies configuration and avoids firewall trouble. And it allows authentication with keys instead of a password, which is both more secure and more convenient.
Configuring it in any modern client is practically identical to FTP: server address, username, password, and choosing SFTP as the protocol with its corresponding port. If your provider offers it, there is no reason to keep using plain FTP.
One detail to keep in mind: on some shared plans SFTP requires the account to have shell access enabled. If the option does not appear, ask support before resigning yourself to FTP.
Key authentication, in two words
Instead of a password, you generate a key pair: a private one that stays on your computer and never leaves it, and a public one you load onto the server. When connecting, it is verified that you hold the matching private key without transmitting it.
The advantages are clear: there is no password to capture, no password to brute force, and access is revoked by deleting the public key from the server. The only discipline it demands is protecting the private key file and giving it a passphrase.
Which to use in each situation
A quick change to one file: panel file manager. Log in, edit, save, done.
Installing a theme or uploading many photos: upload an archive through the panel and extract it there. By far the fastest method.
Daily development work: SFTP with a desktop client. You can keep the project synchronized, compare versions and upload only what changed.
Migrating an entire site: archive plus panel, or the command line directly if you have access. Never file by file.
Common upload mistakes
Uploading to the wrong folder. Mistake number one. Site files go in the public folder, usually called public_html or www. If you upload to the account root directory, the site cannot see them. If the domain is an addon or a subdomain, the correct folder is different: verify it in the panel.
Incorrect permissions. After uploading over FTP, files can end up with permissions the server cannot read, and a 403 error appears. The general rule: 644 for files, 755 for folders. And never 777, even if an old tutorial suggests it: that opens the file to anyone.
Binary versus text mode. FTP clients have two transfer modes. If you upload an image in text mode, it gets corrupted. Modern clients detect this on their own, but if a file arrived damaged, check this.
Hidden files that never get copied. Files starting with a dot, such as the server rules file, are hidden by default in many clients. During a migration, forgetting them means losing every redirect and all your clean URLs. Enable hidden file display before copying.
A note on syncing and deployment tools
Once you move past occasional edits, uploading by hand stops making sense. Desktop clients can compare local and remote folders and transfer only what changed, which turns a ten-minute upload into a five-second one. If you work with version control, the natural next step is deploying from the repository, so what reaches the server is exactly what you committed and nothing else.
Whatever tool you choose, one rule saves a great deal of pain: never edit files directly on the production server for anything beyond a trivial fix. The change exists nowhere else, nobody can review it, and the next deployment silently overwrites it. Edit locally, test, and upload. The file manager is for emergencies, not for building.
Access hygiene
Two practices that prevent unpleasant surprises. First: create one access account per person or per project instead of sharing the main one. When a collaborator stops working with you, you delete their account and that is it, without changing the password for everything.
Second: periodically review which access accounts exist. It is common to find logins created years ago for a developer who is long gone, still active and with full permissions. Every one of those is an open door.
If your host lets you create accounts restricted to a specific folder, better still: the designer who only touches the theme folder does not need to see the configuration file with your database credentials. At BanaHosting that is managed from cPanel alongside the rest of your access settings, so reviewing who has what is a couple of clicks.