Hi! As in the title - trying to download any model or quantization at all results in an “Access Denied” XML response, even for models I have downloaded in the past (like, even a few weeks ago). Is HuggingFace down or something? I have no emails to my account besides the email verification, so I doubt I’ve been locked or anything like that, and these models are open-weights and should be downloadable - so this is really throwing me for a loop. Thanks!
same issue, so its probably something on their end
I’m getting this on every single download attempt right now
AccessDeniedAccess denied
This XML file does not appear to have any style information associated with it. The document tree is shown below.
AccessDenied
Access denied
…
Same Here. Just getting AccessDeniedAccess denied
This XML file does not appear to have any style information associated with it. The document tree is shown below.
AccessDenied
Access denied
…
And it’s very irritating.
ANY IDEA WHAT’S GOING ON?
I am also getting this 403 error even when downloading a 10 MB file via the browser…
Just yesterday I downloaded some models using a regular fetch, and now it has stopped working. Moreover, if you run:
hf repository/name model2.onnx model_name.onnx --local-dir ./models
The file downloads perfectly fine.
Using @huggingface/transformers.js is way too redundant for me—it includes too many things that I simply don’t need.
Might be down. Also experiencing the same issue.
Does anyone have a workaround?
I ran a quick Colab experiment around this cluster of issues:
Short answer
This looks much more like a service-side file-delivery problem than an account lock, gating problem, or permission mistake on your side.
Shortly after the reports in this thread, I could reproduce XML AccessDenied responses against public, non-gated files without using an HF token. More importantly, repeated requests for the same repository, file, and byte range alternated between:
- HTTP
206 Partial Contentwhen the final delivery host wasus.gcp.cdn.hf.co - HTTP
403 AccessDeniedwhen the final delivery host wascas-bridge.xethub.hf.co
That makes a user-specific account restriction unlikely. In this test, the result followed the delivery route rather than the model permissions or a particular byte offset.
I cannot determine the internal root cause from an external probe. Plausible areas include route selection, signed-URL generation, bridge/origin access, CDN configuration, or propagation between storage paths. The terminal hostname is where the failure became visible; it is not necessarily the component that caused it.
What I would do first
- Try the download again now. This may have been a transient incident.
- If it now works, note the approximate UTC recovery time. That would still help correlate the reports.
- If it still returns XML
AccessDenied, preserve:- UTC timestamp
- repository and filename
- whether it was a browser, direct link,
hf download, Python, or another application - HTTP status
- final delivery hostname
- XML
RequestId,HostId, or CDN request ID, if present
- Do not publish the query string of the redirected URL. It can contain temporary signed credentials.
- I would not delete/re-upload repositories, regenerate tokens, or alter gating settings based on this symptom alone.
A useful first distinction is:
- XML
AccessDeniedfrom a direct/browser-style download: likely a file-serving or redirected-delivery-path problem. hf downloadsilently freezing during “Reconstructing”: likely an Xet client/CAS/reconstruction path problem.
Both happened in the same time window, but the experiment below does not prove that they have one root cause.
Experiment setup and detailed results
Test setup
I ran the test from a fresh Colab Free runtime starting shortly after the reports on July 13, 2026.
The test used:
- no Hugging Face token
- public repositories only
- fresh download/cache directories
- repeated HTTP Range requests
- manually recorded redirect chains
- a public control model
- bounded
hf downloadruns with a stall watchdog - redacted logs with signed query values removed
Main target:
juiceb0xc0de/bella-bartender-gemma-e4bmodel.safetensors- approximately 15.9 GB
- Xet-backed according to Hub metadata
Control:
openai-community/gpt2model.safetensors- public and non-gated
The Range tests requested only 256 KiB at each position. Their purpose was not to download the whole model, but to distinguish among:
- a broken fixed byte range
- a broken backing object
- a route-dependent failure
- intermittent network failure
- a repository-specific permission problem
The target offsets included:
| Offset class | Approximate position |
|---|---|
| Start | 0 |
| Before reported stop | 1.9 GB |
| Reported stop area | 2.0 GB |
| After reported stop | 2.1 GB |
| Middle | approximately half of the file |
| Near end | final 256 KiB |
The requests were shuffled over time so that a temporary recovery or degradation would be less likely to look like an offset-specific result.
Result 1: the 403 followed the final delivery route
There were 72 repeated Range requests against the target file.
| Final delivery host | Attempts | Result |
|---|---|---|
us.gcp.cdn.hf.co |
44 | 44 × HTTP 206 success |
cas-bridge.xethub.hf.co |
28 | 28 × HTTP 403 XML AccessDenied |
The same pattern appeared across all tested parts of the file:
| Byte-range class | Successful route observed | AccessDenied route observed |
|---|---|---|
| Start | Yes | Yes |
| ~1.9 GB | Yes | Yes |
| ~2.0 GB | Yes | Yes |
| ~2.1 GB | Yes | Yes |
| Middle | Yes | Yes |
| Near end | Yes | Yes |
In other words, an identical byte offset could succeed in one repetition and fail in another.
The successful and failed requests referred to the same repository, revision, filename, and Xet object metadata. The main visible difference was the redirected delivery route.
A public GPT-2 control object also produced both outcomes: successful responses through the GCP CDN route and AccessDenied responses through the bridge route. That makes a problem limited to the target model or its repository settings less likely.
What this supports
The observations support a failure somewhere around the delivery-path boundary, for example:
- route selection
- signed URL generation
- origin or bucket access
- CDN/bridge configuration
- stale or partially propagated policy
- a transition between old and newer serving paths
What this does not prove
It does not prove that:
cas-bridge.xethub.hf.coitself is the root cause- the resolver selected the wrong host
- the underlying object is missing
- a particular storage provider was down
- every user or geographic region was affected
- all reports in this time window came from one incident
This was a black-box test from one Colab region. The terminal host shows where the request ended, not necessarily where the original fault occurred.
Why the route distinction may matter
Hugging Face documents a compatibility path for clients that do not interact with Xet directly. In that path, a bridge service translates conventional Git LFS-style file requests into access to Xet-backed content.
The relevant background is described in the official Backward Compatibility with LFS documentation.
That distinction matters because:
- a browser or ordinary HTTP client may use a bridge/file URL
- an Xet-aware client may retrieve reconstruction metadata and byte ranges through a different path
- a direct HTTP
403and anhf-xetreconstruction stall do not necessarily represent the same internal failure
The strongest statement supported by this experiment is therefore:
The observed
AccessDeniedresult was route-dependent. It was not consistently tied to account permissions, repository visibility, or a fixed byte range.
Related public 403 report
There is a recent open issue with a similar failure class:
That issue reports:
- public, non-gated repositories
- visible repository and file metadata
- backing-file downloads failing with XML
AccessDenied - failures through both CLI and authenticated Python downloads
- multiple repositories and multiple files
The hostname and storage path in that issue are not identical to the ones observed here, so I would treat it as a related class of failure, not confirmation of the same bug.
At the time of writing, that issue remains open.
Result 2: a separate Xet download stall was also reproducible
A nearby thread reported a 15.9 GB model download repeatedly freezing at the same reconstruction point on three independent machines:
Model download freezing at exact percentage
I tested the same target with hf download.
The public GPT-2 control completed normally.
The target model rapidly progressed to approximately:
2,054,857,632 bytes
It then stopped making observable progress. The destination size and Xet cache size remained unchanged for four minutes, after which the watchdog terminated the process.
That is close to the 2.00GB / 15.9GB stop reported in the other thread.
However, this is an important qualification:
- the direct Range tests produced explicit bridge-route
403responses - the full Xet download did not show the same bridge XML error
- the Xet log showed successful
206range traffic through the GCP CDN before progress stopped
Therefore I would currently report these as two observed failure modes:
- Route-dependent direct HTTP
AccessDenied - A reproducible Xet reconstruction/download stall
They may be related at the level of a broader service incident, but the data does not establish a direct causal chain such as “the bridge 403 caused the Xet client to freeze.”
There is also an open Xet hang report predating these forum threads:
Unable to download models with Hugging Face — huggingface_hub #4508
That issue reports:
- recurring hangs across several large models
- failures most of the time
- successful but slower downloads when Xet is disabled
hf_xet 1.5.1- long periods with no cache or destination growth
At the time of writing, #4508 also remains open.
Contemporaneous Parquet API / Dataset Viewer failure
Several hours before the model-download reports, users also reported failures in the Parquet API and embedded Dataset Viewer:
URL is not fetched from the Parquet API
During the same Colab session, I repeated both relevant API calls five times.
Observed results:
| Endpoint class | Attempts | Result |
|---|---|---|
| Hub Parquet API | 5 | 5 × HTTP 400 |
datasets-server Parquet API |
5 | 5 × HTTP 503 with an HTML error page |
The Hub-facing response included the same general symptom reported in the thread: an upstream HTML response being encountered where JSON was expected.
This is useful evidence that another HF backend was malfunctioning in the same time window. It makes “several unrelated users all misconfigured their accounts at once” even less plausible.
It still does not prove that the Parquet API failure and model file-delivery failure shared one internal root cause.
Status-page note
I could not find a matching official incident entry for these July 13 reports.
The public Hugging Face status page showed the CDN components as operational for that date. That should be recorded as “no matching public incident was listed,” rather than treated as proof that no partial, regional, route-specific, or short-lived incident occurred.
The reproduced failures were narrow enough that a high-level health check could plausibly remain green:
- Hub metadata was available
- repository pages were available
- small files could work
- some large-file routes worked
- another route returned
403 - the control Xet download could complete
- a particular large Xet download could still stall
Minimal diagnostics if the problem continues
The default path I would use is:
If a browser or direct link returns XML AccessDenied
Record:
- UTC timestamp
- repository
- filename
- HTTP status
- final hostname
- XML request IDs
- whether regenerating the download link changes the result
Do not post the complete redirected URL. Strip everything after ?.
A small public Range request can test the serving path without downloading the entire model:
curl -sS -L \
--range 0-262143 \
--output /dev/null \
--write-out $'status=%{http_code}\nfinal_url=%{url_effective}\n' \
'https://huggingface.co/<repo_id>/resolve/main/<filename>'
The printed final_url may contain a signed query. Before sharing it, reduce it to the scheme, hostname, and path.
If hf download freezes instead of returning an error
Start with:
hf env
HF_DEBUG=1 hf download <repo_id> <filename>
HF_DEBUG=1 is documented to enable debug logging and log equivalent cURL requests. Review the output before posting because it may include authentication or signed URL information.
The official environment-variable reference documents the relevant controls:
Hugging Face Hub environment variables
Useful diagnostic branches include:
| Observation | Diagnostic branch |
|---|---|
| Xet download hangs, but direct HTTP works | Compare Xet-enabled and Xet-disabled runs |
| High parallelism may be involved | Test a lower HF_XET_NUM_CONCURRENT_RANGE_GETS |
| Reconstruction/write ordering is suspected | Test HF_XET_RECONSTRUCT_WRITE_SEQUENTIALLY=1 |
| Need to determine whether Xet is involved at all | Test HF_HUB_DISABLE_XET=1 |
| Need request-level logs | Use HF_DEBUG=1 |
| Need Rust/Xet logs | Use RUST_LOG=info and HF_XET_LOG_FILE |
For example:
HF_XET_NUM_CONCURRENT_RANGE_GETS=1 \
RUST_LOG=info \
HF_XET_LOG_FILE=/tmp/xet.log \
hf download <repo_id> <filename>
Or, as a diagnostic fallback:
HF_HUB_DISABLE_XET=1 \
hf download <repo_id> <filename>
Disabling Xet may be much slower. I would use it to separate paths, not present it as the general fix for this incident.
The Xet project also provides platform-specific diagnostic guidance:
xet-core diagnostic scripts and debugging notes
The documented logging variables include:
RUST_BACKTRACE=full
RUST_LOG=info
HF_XET_LOG_FILE=/tmp/xet.log
If small files work but weights fail
That points away from basic authentication and repository visibility, and toward the large-object serving layer.
A useful comparison is:
config.json- a large
.safetensors,.bin, or Parquet file - the same large file from another network or region
- a known public control model
If the problem has already disappeared
That supports a transient service-side or propagation problem, but does not identify which component changed.
The most useful remaining datum would be:
- first failure time in UTC
- approximate recovery time in UTC
- whether the same saved link began working, or a newly generated link was required
What I would avoid doing based only on this symptom
I would not immediately:
- delete and recreate the repository
- re-upload a multi-gigabyte file
- change public/private or gating settings
- repeatedly regenerate access tokens
- assume the model owner uploaded a corrupt file
- assume a specific CDN provider is solely responsible
- publish signed URLs or authorization headers
Those actions either do not match the observed route-dependent behavior or can destroy useful evidence before the serving path has been identified.
Bottom line
The observations are most consistent with a temporary or partial Hugging Face-side delivery-path incident, not an account lock.
The strongest concrete result was that the same public file and byte range succeeded through one terminal delivery route and returned XML AccessDenied through another. A separate Xet reconstruction stall and a contemporaneous Parquet API outage were also reproducible, although I would not claim that all three had one root cause without internal confirmation.
For anyone still affected, the safest next step is to preserve the UTC time, final hostname, status code, and request IDs, while avoiding destructive repository changes or publishing signed URL parameters.
I have the same issue for the last 2 hours! Downloading any model and seeing message: Access Denied.
I’m realtive new to this platform and it is very frustrating.. i try to pinpoint the issue with different IP or logged in etc. But as it read here: probably there HF servers?? Where is this status info found? i did not see it anywhere on the website..!
update from https://huggingface.co/proxy/status.huggingface.co/
Resolved: On April 13, 2026, between approximately 13:30 UTC and 19:00 UTC, some users experienced stalled or hung downloads of large files. The issue primarily affected users routed through our US Central CDN endpoints (ORD/DFW regions), particularly when downloading via the XET protocol.
Root cause: An infrastructure issue in Google Cloud’s us-central1 region caused download connections to hang during large file transfers.
Resolution: The underlying infrastructure issue was identified and patched. No user action is required previously working configurations will continue to work as expected.
Affected services: Hub file downloads (XET-enabled repositories)
We apologize for the disruption.
But downloading is still not working for me… hf download is still hanging after 500 to 700 MB.
So problem not solved!?
Perhaps related too: Huggingface docs page is down
Seems to be working for me. If you’re still having the error try again now.
The download seems to be working again.
when try to open this doc page (for the last 1 hour or something): https://huggingface.co/docs/huggingface_hub/en/guides/cli
I got: Internal Error - We’re working hard to fix this as soon as possible!
Edit/update:
Lucky if downloading is working again! But here i just tested downloading again, with hf cli and download direct from website, both failing after about 1 minute.
