# AlphaFold Database Download Error: Causes and Fixes The single most common AlphaFold database download error is a plain HTTP 404 caused by a malformed file URL. The AlphaFold [Protein Structure](/blog/guides/protein-structure) Database (AlphaFold DB), hosted by EMBL-EBI, now holds predicted structures for more than 214 million protein sequences, and every entry is served under a strict filename convention that breaks the moment a single character is wrong [1]. Before you touch proxy settings, cloud credentials, or mirrors, confirm that the URL you are requesting actually follows that convention. This guide walks through every major failure mode, from the most common to the rarest, explains the mechanism behind each one, and gives you a fix you can apply in minutes. ## Start Here: The 60-Second Check Ninety percent of download failures resolve with three checks. 1. **Confirm the protein exists in the database.** Every AlphaFold DB entry is keyed to a UniProt accession. Open `https://alphafold.ebi.ac.uk/entry/{ACCESSION}` in a browser, replacing `{ACCESSION}` with your UniProt ID, for example `P00533`. If the page loads, the entry exists. If the page 404s, no structure is archived for that accession, and no download command will fix that. 2. **Check the filename pattern.** Single-protein files follow the pattern `AF-{UNIPROT_ACCESSION}-F{fragment_number}-model_v{version}.cif`. For EGFR (UniProt P00533), fragment 1, version 4, the filename is `AF-P00533-F1-model_v4.cif`. A missing `AF-` prefix, a lowercase accession, a appended `.pdb`, or a stale version number each produce a 404. 3. **Test in a browser before the terminal.** If the file opens or downloads in a browser but fails in `wget` or `curl`, the problem is on your side, almost always the network, not the database. If all three checks pass and the download still fails, work through the cause list below in order. ## How the AlphaFold Database Distributes Files Understanding the delivery channels makes every error easier to interpret. According to the database maintainers, AlphaFold DB offers four access mechanisms: direct file access over HTTPS, bulk access over FTP, structured querying through Google Cloud Public Datasets, and programmatic REST API endpoints for automated queries [1]. The database grew roughly 500-fold between its 2021 release, which held about 300,000 structures, and the 2024 release, which holds over 214 million [1]. That scale matters for troubleshooting because the bulk routes (FTP and Google Cloud) are designed for large transfers, while the web routes are designed for individual files, and each route fails in characteristic ways. The site also runs a search engine, a 3D viewer with customization options, and a Predicted Aligned Error (PAE) viewer, which was enhanced in the 2024 update [1]. None of those front-end features affect download mechanics, but a search that returns nothing is often misread as a download failure when it is actually a query problem. We cover that in Cause 1. ## Troubleshooting Table This table is the core reference for any alphafold database download error. Find your symptom, confirm the cause, apply the fix. | Symptom | Likely cause | How to confirm | Fix | |--|--|--|--| | HTTP 404 on a file URL | Malformed filename or wrong accession, fragment, or version | Open the entry page `alphafold.ebi.ac.uk/entry/{ACCESSION}` in a browser and copy the file link from there | Rebuild the URL as `AF-{ACC}-F{n}-model_v{ver}.cif`, or fetch the current version number from the entry page | | HTTP 404 on the entry page itself | No AlphaFold model exists for that UniProt accession | Search the accession on the AlphaFold DB website and on UniProt directly | Request the structure through the AlphaFold Server or run a local prediction instead | | Connection hangs, then times out | FTP port blocked by firewall or proxy | FTP fails at every site, HTTPS to the same host succeeds | Switch from FTP to the HTTPS mirror on the same host, or force passive FTP mode | | HTTP 429 or 503 | Rate limiting or server maintenance | Error appears only during heavy scripted loops or during announced maintenance | Add exponential backoff with retries, spread requests over minutes, switch to bulk channels for large jobs | | File size is zero or smaller than expected | Interrupted transfer | Compare byte count against the server-reported size, check the tail of the file | Resume with `wget -c` or `curl -C -` | | Parser crashes on a `.cif` file with a gzip or truncation error | Corrupted download | Try to open the file in a text editor, look for abrupt truncation at the end | Delete and redownload, resume the partial file, verify against the checksum if one is published | | `gsutil` or `gcloud storage` reports access or authentication errors | Wrong bucket path, missing credentials setup, or an API that is not enabled | Run the same command against a known public file | Reinstall or update the Google Cloud SDK, run `gcloud auth login`, verify the bucket path in the official AlphaFold DB documentation | | API returns an error status or empty body | Wrong endpoint or malformed query parameters | Test the same request with `curl -v` and read the response status and headers | Rebuild the request against the documented endpoints, URL-encode query parameters | | SSL or certificate verification error | Outdated system CA certificates, captive portal, or TLS interception | `curl` reports a certificate error that a browser does not | Update the CA bundle, connect from a network without TLS interception, or use `-cacert` with a trusted bundle | | Download dies partway with "No space left on device" | Local disk full | `df -h` on Linux and macOS, or the disk tool on Windows | Free space or redirect output with `wget -O` to a volume with capacity, then resume | | Download works at home, fails at work | Institutional proxy or firewall | Try a different network, check proxy environment variables | Configure `https_proxy`, ask IT to allowlist the host, or use the Google Cloud route which rides standard Google infrastructure | ## Cause 1: Malformed URL or Entry Identifier ![Steps to confirm the entry, read the fragment and version, build the mmCIF filename and download it.](/article-images/illustrations/alphafold-database-download-error-filename-build.webp) This is the most frequent alphafold database download error cause, and it has a precise mechanism. The database stores files under generated names, not arbitrary ones. The pattern is: ``` AF-{UNIPROT_ACCESSION}-F{FRAGMENT}-model_v{VERSION}.cif ``` Three failure points live inside that pattern. **The accession is wrong or absent.** AlphaFold DB does not store structures under gene names, PDB IDs, or RefSeq IDs. It stores them under UniProt accessions. Searching for `EGFR` as a filename fails. Searching for `P00533` succeeds. If you got the accession from a paper, a spreadsheet, or an old annotation, verify it on the UniProt website first. A single stale accession silently produces a 404 that looks like a server problem but is not. **The fragment number is wrong.** Long UniProt sequences are split when they exceed the residue limit that AlphaFold2 was run on, and each fragment becomes its own file. Fragment numbering starts at `F1`. If you copied a link to `F2` from a colleague or an old notebook and your protein only has one fragment, the request 404s. **The version number is stale.** Model versions increment as AlphaFold is retrained and the database is re-predicted. Links copied from tutorials written against version 1 or version 2 can break when those specific files are superseded. The robust fix is to never hardcode the version. Open the entry page and copy the current file link, or scrape the version from the API metadata. A reliable workflow that avoids all three failure points: ```bash # 1. Confirm the entry exists and get the canonical page # (do this in a browser first) # https://alphafold.ebi.ac.uk/entry/P00533 # 2. Download using the exact filename shown on that page curl -O https://alphafold.ebi.ac.uk/files/AF-P00533-F1-model_v4.cif ``` If you are scripting across thousands of accessions, first query the programmatic endpoints described in the database documentation to resolve current file paths, then download from the resolved paths [1]. Do not construct filenames by string concatenation from a version number you hardcoded last year. A related mistake worth naming: some users report a "failed download" when the website search returns nothing. The search engine indexes the database, and its behavior changed with the 2024 update that also brought improved search [1]. An empty search result for a gene name is a query problem, not a transfer problem. Search by UniProt accession or protein name, not by gene symbol alone. ## Cause 2: Network Blocks, Proxies, and Firewalls The second most common failure class lives between your machine and the server. The database distributes bulk files over FTP in addition to HTTPS [1], and FTP is the channel most often broken by institutional networks. **Why FTP fails behind firewalls.** Classic FTP opens a control connection on port 21 and then a second, separate data connection whose port is negotiated dynamically. Stateful firewalls and corporate proxies frequently block that second connection. The symptom is characteristic: you connect, you list a directory or start a transfer, and then the session hangs indefinitely. The fix is passive mode, in which the client initiates both connections, which most firewalls tolerate. Most modern FTP clients default to passive mode, but command-line defaults vary. **The simpler fix is to skip FTP entirely.** The FTP host also serves the same directory tree over HTTPS, so a browser or `wget` can pull the identical files without the second-connection problem: ```bash wget https://ftp.ebi.ac.uk/pub/databases/alphafold/{FIRST_TWO_CHARS_OF_ACCESSION}/AF-P00533-F1-model_v4.cif ``` Directory listings on that tree are organized by the first characters of the accession, which lets you browse to your protein of interest manually if you want to eyeball what fragments and versions exist. **Proxies and VPNs.** Institutional proxies intercept HTTPS and can break certificate validation or long-running transfers. If `curl` works with `-insecure` (only as a diagnostic, never as a routine practice) while normal requests fail, your network is intercepting TLS. Ask your IT group to allowlist the database host or to install their root certificate into your system trust store. VPN split tunneling can also produce a failure that looks like a server outage from one subnet and a client problem from another. **Corporate DNS.** A resolution failure produces the error `Could not resolve host`. Confirm with `nslookup alphafold.ebi.ac.uk` or `dig`. If resolution fails on your network but succeeds on a phone hotspot, the issue is local DNS, not the database. ## Cause 3: Server Load, Rate Limits, and Maintenance The database serves a global user base, and during predictable load spikes the web endpoints respond with HTTP 429 (too many requests) or 503 (service unavailable). The mechanism is deliberate throttling. A scripted loop that requests thousands of files back to back is functionally a denial-of-service pattern from the server's point of view, and the response is to slow you down or refuse you. **How to confirm.** Read the HTTP status code. `curl -I` against the failing URL shows it directly. A 403 or 429 in a tight loop, from one client, within seconds, is rate limiting. A 503 that appears for all URLs, at all times of day, after an announcement, is maintenance. **How to fix it.** - Add exponential backoff to any scripted download. A minimal Python pattern: ```python import time, requests def fetch(url, max_retries=5): for attempt in range(max_retries): r = requests.get(url, timeout=60) if r.status_code == 200: return r.content wait = 2 ** attempt # 1, 2, 4, 8, 16 seconds time.sleep(wait) raise RuntimeError(f"Failed after {max_retries} attempts: {url}") ``` - If you need more than a few hundred files, stop hammering the web endpoint. Move to the bulk channels. The maintainers specifically provide FTP and Google Cloud Public Datasets for large-scale retrieval precisely so that the interactive web service stays responsive [1]. Bulk access through those routes is both more reliable and more polite. - Respect the usage policy. The database is free and open, but automated access is expected to behave like one well-behaved client, not a thousand. ## Cause 4: Interrupted or Corrupted Downloads Long transfers over unstable connections produce truncated files. The mechanism is mundane: TCP connections drop, wireless handoffs occur, laptops sleep. A partially written `.cif` file can be several megabytes of valid-looking text followed by an abrupt end, and the failure only surfaces later, when a parser such as BioPython, gemmi, or a visualization tool chokes on the missing final records. **Confirm corruption.** ```bash # Check the tail of the file for abrupt truncation tail -n 5 AF-P00533-F1-model_v4.cif # Compare local bytes with the server-reported size curl -sI https://alphafold.ebi.ac.uk/files/AF-P00533-F1-model_v4.cif | grep -i content-length ls -l AF-P00533-F1-model_v4.cif ``` **Fix with resume.** Both mainstream tools support resuming a partial transfer instead of restarting: ```bash wget -c https://alphafold.ebi.ac.uk/files/AF-P00533-F1-model_v4.cif curl -C - -O https://alphafold.ebi.ac.uk/files/AF-P00533-F1-model_v4.cif ``` **Verify before you analyze.** For any file that matters downstream, compare the byte count you received against the server-reported size. Where the distribution channel publishes a checksum, compare it. For scripted pipelines, treat a file that parses cleanly as the acceptance criterion, and log every file that fails parsing so you can redownload only those. This habit converts a mysterious pipeline crash into a five-line retry script. ## Cause 5: Bulk Download and Google Cloud Problems For proteome-scale work, downloading individual files is the wrong tool. The database is mirrored as a Google Cloud Public Dataset, and the maintainers document structured queries against it through that channel [1]. Errors on this route have their own signatures. **Authentication and setup errors.** The `gsutil` and `gcloud storage` tools require the Google Cloud SDK to be installed, initialized, and authenticated. The classic failure is running a cloud command on a machine where the SDK was never configured. Run `gcloud auth login` and `gcloud config set project {PROJECT_ID}` before any storage command. A second classic failure is an SDK old enough that its default APIs or endpoints have moved. Updating the SDK resolves a surprising share of these errors. **Wrong bucket path.** Bucket paths change and paths are case-sensitive. Copy the exact bucket and path from the current AlphaFold DB access documentation rather than from a blog post or an old answer on a forum. A one-character difference in a bucket name produces an access error that looks like a permissions problem when it is a typo. **Scale shock.** The full database at over 214 million entries is far beyond anything you should pull to a laptop [1]. Plan for scale deliberately: - For one proteome, filter first. Use the cloud querying channel to list the accessions you actually need, then download only those files. - For everything, use cloud-to-cloud analysis. Copy the data to your own cloud project and analyze it there, so the data never crosses the internet to your workstation. - Estimate transfer time before starting. A petabyte-scale download over a 1 Gbps link runs for months. No configuration fix makes that sensible. **Egress surprise.** Cloud providers bill for data leaving their network in most configurations. Reads from a public dataset into your own cloud project typically avoid that charge, while downloads to your local machine may not. Check your cloud billing model before bulk-pulling data to a workstation. ## Cause 6: Programmatic API Errors The database exposes programmatic access endpoints intended for automated queries, and the 2024 update refined these access mechanisms alongside the FTP and cloud routes [1]. API errors follow a small set of patterns. **Malformed requests.** Query parameters must be URL-encoded. A UniProt accession pasted with a trailing space or newline produces a request the server cannot match. Print the exact URL your script sends (`repr()` in Python, or `curl -v`) and inspect it character by character. This one debug step resolves most API mysteries. **Interpreting status codes.** A 404 from the API means the identifier was not found, which usually means the accession does not exist in the database rather than that the service is down. A 5xx means the service had a problem, and retrying with backoff is appropriate. A 403 means the request was refused, which in practice points to rate limiting or a policy violation in how you are calling. **API versus file endpoint confusion.** The programmatic endpoints return metadata and identifiers. The structure files themselves come from the files endpoint. Scripts that query the API and then assume the API response is the structure produce a JSON-parse error that gets reported, incorrectly, as a download failure. Separate the two steps in your code and in your mind. **Keep request rates sane.** The same throttling logic that governs web downloads applies to the API. Insert delays between calls in any loop, cache responses you have already fetched, and batch queries where the endpoint supports it. ## Cause 7: Local Environment Failures Sometimes the database is fine, the network is fine, and the failure is entirely on your machine. **Missing tools.** On a fresh macOS install, `wget` is absent by default. Install it with Homebrew (`brew install wget`) or use `curl`, which ships with the operating system. On Windows, `curl.exe` ships with recent versions and runs in PowerShell, while bare `curl` in PowerShell is an alias for `Invoke-WebRequest` with different flags, a frequent source of confused error messages. **Outdated TLS roots.** Old operating images fail certificate verification against modern servers. Updating the system CA certificate bundle (the `ca-certificates` package on most Linux distributions) resolves it. **Disk space.** A full volume fails mid-write, which surfaces as either a truncated file (Cause 4) or an explicit write error. Check capacity before any large batch, and point `wget -O` or `rsync` at a volume with headroom. **Untrusted scripts.** A short safety note. Pasting download commands from a forum is normal practice, but piping a remote script directly into a shell (`curl ... | bash`) executes whatever that URL serves at that moment, on your credentials, with no chance to review it. Download the script, read it, then run it. The same rule applies to notebook cells copied from shared notebooks. This habit prevents both security problems and the silent misconfiguration class of download errors. ## Choosing a Download Method Different jobs need different channels. Match the method to the job and most download errors never occur. | Method | Best for | Typical command | Watch out for | |--|--|--|--| | Web download | A handful of structures, visual inspection | Browser, or `curl -O` on a file URL | Hardcoded stale version numbers | | HTTPS directory (FTP mirror over HTTPS) | Dozens to hundreds of files, scripted loops | `wget -r` or `wget -i filelist.txt` on the HTTPS tree | Recursive flags that pull far more than you need | | FTP | Legacy pipelines already built around it | `lftp` with passive mode | Firewall-blocked data connections, prefer HTTPS | | Google Cloud Public Datasets | Proteome-scale and cross-proteome queries, cloud analysis | `gcloud storage` commands after SDK setup | SDK setup, bucket path accuracy, egress costs | | REST API | Resolving accessions and metadata inside pipelines | `curl` or `requests` against documented endpoints | Rate limits, URL encoding, confusing metadata with files | The maintainers built this layered access design on purpose, so that small interactive queries, scripted medium jobs, and proteome-scale analysis each have an appropriate route [1]. Match your workload to the right layer before debugging anything. ## A Worked Download Tutorial Here is a complete, reproducible example for one protein, end to end, in the style of a short alphafold tutorial. Suppose you want the predicted structure of human EGFR. 1. **Find the UniProt accession.** Search UniProt for "EGFR human". The canonical human EGFR entry is P00533. Write the accession down. Everything else derives from it. 2. **Open the AlphaFold entry page.** Navigate to `https://alphafold.ebi.ac.uk/entry/P00533`. Confirm a structure exists, glance at the confidence coloring in the viewer, and note the fragment list. EGFR is a long protein, so expect more than one fragment. 3. **Copy the exact file link.** On the entry page, use the download control, or construct the filename from the visible version and fragment. For fragment 1, version 4, the file is `AF-P00533-F1-model_v4.cif`. 4. **Download to a project directory.** ```bash mkdir -p ~/projects/alphafold && cd ~/projects/alphafold curl -O https://alphafold.ebi.ac.uk/files/AF-P00533-F1-model_v4.cif ``` 5. **Verify integrity.** Check the file size against the server header and open the file to confirm the mmCIF records are present and the file does not stop abruptly. 6. **Load and inspect.** Open the file in PyMOL, ChimeraX, or a Python session with gemmi to confirm the model loads and the B-factor column carries the pLDDT confidence values you expect. 7. **Repeat or scale.** For one more protein, repeat. For a thousand proteins, switch to the HTTPS directory tree or the cloud channel per the table above. This sequence, entry page first, exact filename second, verification third, prevents the two errors that consume most troubleshooting time: the 404 from a guessed filename and the corrupted file from an unverified transfer. ## Common Mistakes and Limitations These are the errors that show up repeatedly in real labs, stated plainly. - **Assuming PDB-format files are available.** The database distributes structures in mmCIF format with PAE data as separate JSON files. Older releases and some mirrors included PDB-format files, but current bulk distribution is mmCIF-based. Scripts that expect `.pdb` files need updating or an explicit conversion step. Plan for mmCIF-aware tooling. - **Confusing the database with the AlphaFold server.** AlphaFold DB is an archive of precomputed predictions that you download. The AlphaFold Server is an interactive service from Google DeepMind that runs new predictions on sequences you submit, with usage limits designed for interactive scientific use rather than bulk jobs. A "download error" from the server-side prediction interface is a different problem from a database file download and needs a different fix: reduce the input, split long complexes, or run a local prediction pipeline such as ColabFold or the AlphaFold codebase for large workloads. - **Downloading the whole database when you need a slice.** The most expensive mistake in this space is pulling data you will never read. Query first, filter, then download. The cloud querying channel exists to support exactly that pattern. - **Treating predictions as experimental structures.** Every entry in the database is a computational prediction with per-residue confidence encoded in the file. Regions with low pLDDT are frequently intrinsically disordered in reality, and the PAE block describes relative positioning uncertainty between residues. A low-confidence loop that looks like a modeling error is the model honestly reporting its uncertainty. Read the confidence data before interpreting any structure. - **Ignoring fragment structure for long proteins.** Assuming a single file covers a full-length UniProt sequence when the entry is split across fragments leads to models that appear truncated. Check the entry page for the complete fragment list. - **Mixing model versions within one analysis.** Version 2 and version 4 predictions of the same protein can differ. When comparing structures across a proteome, record the version alongside every file and analyze within one version. - **Blaming the server first.** In practice, local causes (bad filename, blocked port, full disk, stale SDK) outnumber server-side causes. The diagnostic sequence below is ordered to catch local causes first for that reason. A final limitation. Predicted structures are a starting hypothesis for mechanism, mutagenesis, or docking, not a substitute for experimental validation of the specific conformation your question depends on. Individual research cases need domain expertise and, where the structure matters to a conclusion, experimental evidence. ## A Diagnostic Sequence You Can Follow ![Decision path that sorts an AlphaFold download failure by browser test, HTTP status code and network test into the right fix.](/article-images/illustrations/alphafold-database-download-error-error-triage.webp) When a download fails and the table alone does not resolve it, run this sequence in order. 1. **Reproduce the failure in a browser.** Paste the exact URL into a browser. If it works there, the problem is your client or network. If it 404s there, the problem is the URL or the entry. 2. **Read the actual error.** Run `curl -v` against the URL and read the status code and headers. Distinguish 404 (wrong identifier), 403 or 429 (refused or throttled), 5xx (server-side), and connection-level failures (network). 3. **Test one known-good URL.** Download a file for a protein you have never touched, chosen from the database website, with the link copied directly from the page. If that succeeds, your access path is healthy and the original failure was identifier-specific. 4. **Test a second network.** A phone hotspot is the fastest way to separate your institutional network from everything else. 5. **Check the local machine.** Disk space, tool versions, CA certificates, proxy environment variables (`env | grep -i proxy`), and SDK authentication state. 6. **Escalate the channel.** If the web endpoint is unhealthy for you, move the same job to the HTTPS directory tree or the cloud mirror. Because the maintainers deliberately provide multiple independent access routes [1], a failure isolated to one route almost always has a workaround on another. 7. **Wait and retry with backoff.** For 5xx and rate-limit responses, scheduled retries with growing intervals resolve the majority of cases without any other change. ## Prevention Practices A few habits eliminate most recurrence. - **Never hardcode file URLs in scripts.** Resolve the current filename from the entry metadata at runtime, or store the resolved URL in a manifest that a separate step validates before download. - **Build verification into the pipeline.** After every download step, check the byte count against the server-reported size and attempt a parse. Fail loudly and redownload automatically on mismatch. - **Cache aggressively.** Keep a local, organized store of downloaded files keyed by accession and version. Never download the same file twice in one project. - **Log every request.** URL, timestamp, HTTP status, and file size, one line per file. When something breaks three weeks later, that log turns an afternoon of debugging into a five-minute lookup. - **Match the channel to the workload.** Individual files from the web, batches from the HTTPS tree or FTP, proteome-scale from Google Cloud [1]. Resist the temptation to script ten thousand requests against the interactive web service. - **Pin model versions in your records.** Note the version in filenames, notebooks, and methods sections. Reproducibility in structural work depends on it. - **Keep the SDK current.** If you use the cloud channel, update the Google Cloud SDK on a schedule, because endpoint and default changes in the tooling cause avoidable access errors. - **Monitor the service status.** Before a large scheduled transfer, check the host institution's service status pages for announced maintenance windows so you do not debug an outage that was already announced. ## Frequently Asked Questions ### Why does my AlphaFold database download return a 404 error? A 404 almost always means the filename does not match the database's naming pattern `AF-{ACCESSION}-F{fragment}-model_v{version}.cif`, or the UniProt accession has no archived structure. Open the entry page for your accession on the AlphaFold DB website and copy the download link directly from that page rather than constructing it by hand. ### How do I download AlphaFold structures in bulk? Use the FTP service, the HTTPS mirror of the FTP tree, or the Google Cloud Public Datasets channel, all documented by the database maintainers for large-scale access [1]. For proteome-scale work, query the cloud dataset to filter to the accessions you need before transferring anything, because the complete database is far too large for a workstation download. ### Why is my download slow or timing out? Slow transfers usually reflect your network path, an overloaded connection, or FTP data channels blocked by a firewall rather than the database itself. Switch from FTP to HTTPS, force passive FTP mode if you must use FTP, resume interrupted transfers with `wget -c`, and consider the Google Cloud mirror for large jobs [1]. ### What is the difference between AlphaFold DB and the AlphaFold server? AlphaFold DB is a read-only archive of over 214 million precomputed structures that you browse and download [1]. The AlphaFold server is an interactive service that generates new predictions for sequences you submit, subject to usage limits. Download errors belong to the database, prediction errors belong to the server, and large-scale prediction workloads belong on local pipelines instead of the interactive server. ### Why is there no AlphaFold structure for my protein of interest? The database covers predicted structures for proteins in the source proteomes it was built from, keyed by UniProt accession [1]. If your accession has no entry, the protein may fall outside the archived proteomes or the identifier you are using may be stale. Verify the accession on UniProt, and if no prediction exists, submit the sequence to a prediction server or run a local prediction. ### How do I verify a downloaded AlphaFold file is not corrupted? Compare the local file size against the server-reported Content-Length header and open the file to confirm it does not end abruptly mid-record. For pipelines, make a successful parse of the mmCIF file the acceptance test, and log and redownload any file that fails. ### Can I download AlphaFold structures in PDB format? Current AlphaFold DB distribution is based on mmCIF files, with PAE data supplied as separate JSON files. Older releases and some third-party resources included PDB-format files, but plan your tooling around mmCIF, and convert explicitly if a legacy tool requires PDB format. ### Does downloading from AlphaFold DB cost money or require registration? No. AlphaFold DB is free, open, and integrated with resources such as PDB, UniProt, Ensembl, InterPro, and MobiDB without any registration for standard access [1]. Costs only enter the picture on the cloud side, where your own cloud project's transfer and storage billing applies to how you move and analyze the data. ## Sources 1. [AlphaFold Protein Structure Database in 2024: providing structure coverage for over 214 million protein sequences.](https://pubmed.ncbi.nlm.nih.gov/37933859/)