Hello,
I sent an email to website@huggingface.co on June 15 requesting a rename of my organization from DZER-Studios to Vexion-LM. I have not received any response and the organization name has not changed. Could someone please advise whether organization renames are still supported and if there is another way to contact the team regarding this request?
Thank you.
Issue resolved. Thank you
There were no responses for a long time, so I decided that it wasn’t as important to change the name anymore. I didn’t want to delete the post or write “it’s no longer necessary.” And the post didn’t get deleted.
Hmm… The difficulty here is that almost no one on the user side, myself included, of course, seems to know either a generally applicable answer or even enough reliable clues to derive one, and the information available online is uncertain overall. That makes this difficult to answer. Plus, since the email address you already sent is the official support channel, I wasn’t sure if the user needed to provide any additional information… More specifically, this is what I could find:
This is an organization username / namespace rename, not a personal-account username change and not merely a change to the organization’s display name.
There are several public clues that organization namespace renaming is—or at least has been—supported:
Account > Org username, rather than Profile > Organization name. The user reported that this solved the problem.org.rename separately from org.settings.profile, suggesting that a namespace rename and a profile update remain distinct operations in the current system.So the relevant place for an administrator of DZER-Studios appears to be:
Organization settings → Account → Organization Username
I can personally confirm that the Organization Username field still appears in the current UI and that its description identifies it as the value used in the organization URL and as the namespace for Models, Datasets, and Spaces.
However, I was viewing an organization where I am not an admin, so the field was read-only for me. That confirms only that the field still exists. It does not establish whether an admin can currently edit it, whether every organization is eligible, or whether staff involvement is required in some cases.
The practical situation therefore divides into four branches:
| What an organization admin sees | Practical interpretation |
|---|---|
| The field is editable | Self-service namespace renaming is probably available for that organization. The confirmation text or warning shown before saving would be the most current source of information. |
| The field exists but is read-only | The operation may depend on permissions, organization state, prior renames, existing resources, plan, or staff intervention. An ordinary forum user cannot determine which condition applies. |
| The field is absent | The UI may differ by permission or organization state, or the interface may have changed. Its absence alone would not prove that renaming is unsupported. |
Vexion-LM is rejected |
The namespace may be occupied, reserved, retained as an alias, normalized differently, or rejected by another validation rule. The actual error message or HF staff would be needed to identify the reason. |
website@huggingface.co also appears to be a plausible public route for account and organization-administration issues. I could not find a published response-time guarantee or a page identifying it as a dedicated organization-rename queue, so I would not conclude either that the address was wrong or that the lack of a reply means renaming is unsupported.
Since “Issue resolved” was later clarified to mean that the rename was no longer important enough to pursue—not that the organization was successfully renamed—the technical question remains unresolved for future readers.
These are separate layers:
| Item | What it changes |
|---|---|
| Organization display name | The human-readable name shown on the organization profile. |
| Organization username / namespace | The identifier used in URLs and repo IDs, such as DZER-Studios/model-name. |
| Individual repository name | The final portion of one Model, Dataset, or Space ID. |
| Personal username | The namespace belonging to an individual account. Personal username limits should not automatically be assumed to apply to organizations. |
For this request, the intended operation is approximately:
DZER-Studios/*
↓
Vexion-LM/*
Changing only Profile → Organization name may change the visible profile name without changing identifiers such as:
DZER-Studios/model-name
DZER-Studios/dataset-name
DZER-Studios/space-name
The 2023 Graphext case is the clearest public example.
The user had changed the visible organization name, but newly created repository paths still used the original organization username. HF staff explained that the relevant setting was:
Account > Org username
rather than:
Profile > Organization name
The current Audit Logs documentation also distinguishes:
org.rename
org.settings.profile
This suggests that a namespace rename is treated as a separate system operation rather than as an ordinary profile edit.
It still does not tell us:
| Date | Public trace | What it supports | What it does not prove |
|---|---|---|---|
| 2021 | HF staff discussed a full organization migration involving existing repositories | Organization namespace migrations have existed and could include existing repos. | Current GUI behavior or current redirect policy. |
| 2021 | The user reported that the migration appeared successful | At least one staff-assisted migration completed successfully. | That a modern self-service rename behaves the same way. |
| 2023 | HF staff directed a user to Account > Org username |
A user-facing GUI route existed and apparently solved that case. | Whether all organizations can still use it. |
| 2024 | HF staff said the user could update the organization username | Organization usernames remained user-updatable in at least some circumstances. | Exact conditions or confirmation that the final rename succeeded. |
| 2026 | Current non-admin UI observation | The Organization Username field still exists. | Whether it is editable by an admin. |
| 2026 | org.rename appears in current Audit Logs docs |
Rename remains a recognized operation distinct from profile updates. | Who can execute it and from which interface. |
| 2026 | Another user asked the same redirect questions | The current behavior is not clear from public documentation. | Any answer; that thread currently has no official response. |
In the historical 2021 case, HF staff explained that the organization already had models, so the migration required moving them in the storage backend.
The staff member also warned that, at that time:
The migration was subsequently performed, and the organization user reported that everything appeared to work and that external links had been updated.
This is strong evidence that a full organization migration has been completed successfully before.
It is not reliable evidence about the redirect behavior in 2026. The Hub, its storage implementation, and its client libraries have changed substantially since 2021.
The 2023 case is unusually direct:
The main limitation is that the case concerned capitalization:
Graphext
→
graphext
A change from:
DZER-Studios
→
Vexion-LM
is a more substantial namespace change and may be subject to different validation or migration rules.
The 2024 case involved a personal account occupying a name wanted by an organization.
After HF staff changed the personal-account side, the staff response said that the user could update the organization username.
This supports the existence of a user-side update mechanism in late 2024, but the thread does not show:
I could not find current public documentation that establishes:
Most of these are not realistically verifiable by an ordinary non-admin user. The safest treatment is simply to state that they are unknown rather than fill the gaps with assumptions.
The current Managing organizations documentation mentions the Account tab, but its public explanation focuses on setting an organization email domain.
It does not document:
The organization access-control documentation says:
read provides read-only access to organization repositories and metadata/settings;write allows a member to create, delete, or rename individual repositories in the organization namespace;admin additionally allows profile updates, API-token rotation, and member management.The important distinction is that the documented write permission concerns renaming repositories inside the namespace. It does not say that the member may rename the namespace itself.
Similarly, “update the organization profile” should not automatically be interpreted as “change the organization username,” especially because the audit-log event model distinguishes org.rename from org.settings.profile.
So there is a genuine documentation gap here.
Whether the namespace can be changed and what happens after it changes are separate issues.
For an individual repository, the current Repository Settings documentation explicitly states that renaming or transferring the repo:
However, I could not find an equivalent current guarantee for changing an entire organization namespace.
The June 2026 forum question about organization rename redirects asks almost exactly the missing questions:
At the time of writing, it has no official answer.
Therefore, the documented guarantees for one repository should not automatically be generalized to:
old-org/*
→
new-org/*
A historical example shows why “the old web page redirects” is not necessarily sufficient.
A 2022 Transformers issue involving KB/... and KBLab/... recorded the following behavior with the versions tested at the time:
| Access method | Old identifier worked? |
|---|---|
| Opening the old URL in a browser | Yes; it redirected |
git clone |
Yes |
huggingface_hub.model_info(...) |
Yes |
AutoModel.from_pretrained(...) |
No |
A related huggingface_hub issue identified a problem in redirect handling within hf_hub_download, and a corresponding fix was merged in August 2022.
This should not be read as evidence that current clients are broken, or even that this was exactly the same type of organization-wide rename.
The reusable lesson is narrower:
A working browser redirect does not prove that Git, the Hub API,
huggingface_hub, Transformers, Datasets, Spaces, and external integrations all behave identically.
This is the strongest indication that self-service renaming is available for the organization.
Before saving, the important source is the current confirmation text or warning shown by the UI. It may contain information not available in public documentation, such as:
If the UI gives no migration details, the rename may still be technically available while the compatibility policy remains unclear.
This is probably beyond what another ordinary forum user can diagnose.
Possible categories include:
The disabled field alone cannot identify which category applies.
In that branch, an HF staff response or a reply from website@huggingface.co would be the relevant source of truth.
Vexion-LM is rejectedThis does not necessarily mean that a visible active account currently owns the name.
Possible categories include:
The specific error message would be more informative than public search results.
Then there is no operational reason to continue pursuing it.
However, the thread remains useful for future readers because “Issue resolved” should not be interpreted as evidence that:
The following are not proven blockers. They are resource types or states worth inventorying before a namespace migration.
The official DOI documentation says that repositories locked by a DOI cannot normally be renamed, deleted, or have their visibility changed without support involvement.
It does not document how those repositories behave during a whole-organization rename.
This is one concrete example showing why an organization-wide migration may require more than an ordinary profile update.
For a single Space transfer, HF staff previously confirmed in a successful Space-move case that likes and the hardware grant should remain.
That case concerned one Space, not a full organization namespace rename.
The Space embedding documentation also notes that a Space’s direct URL changes when the Space is moved or renamed.
These are separate identifiers:
https://huggingface.co/spaces/old-org/space-name
https://old-org-space-name.hf.space
A redirect on the Hub page does not necessarily establish the behavior of the direct *.hf.space address.
Depending on the organization, the inventory may also include:
I could not find public documentation describing how all of these behave during a full organization namespace rename.
They should be treated as verification targets, not as known blockers.
The new namespace should become the canonical reference.
Even if old identifiers redirect, it would be safer to update hardcoded repo IDs and Git remotes rather than depend indefinitely on undocumented compatibility behavior.
| Layer | Old form | New form | What to observe |
|---|---|---|---|
| Organization page | old organization URL | new organization URL | Redirect and canonical URL |
| Model page | DZER-Studios/model-name |
Vexion-LM/model-name |
Files, metadata, discussions |
| Dataset page | DZER-Studios/dataset-name |
Vexion-LM/dataset-name |
Page and loading behavior |
| Space page | DZER-Studios/space-name |
Vexion-LM/space-name |
Hub page and runtime |
| Git | old remote | new remote | Clone, fetch, pull, push |
| Hub API | old repo ID | new repo ID | Returned canonical ID |
| Transformers | old model ID | new model ID | Config and model resolution |
| Datasets | old dataset ID | new dataset ID | Dataset resolution |
| Direct Space URL | old *.hf.space |
new *.hf.space |
Reachability or redirect |
| External references | hardcoded old IDs | updated new IDs | Stale links and configuration |
git ls-remote https://huggingface.co/DZER-Studios/<repo>
git ls-remote https://huggingface.co/Vexion-LM/<repo>
from huggingface_hub import HfApi, hf_hub_download, snapshot_download
from transformers import AutoConfig
api = HfApi()
for repo_id in [
"DZER-Studios/<model>",
"Vexion-LM/<model>",
]:
print(f"\n== {repo_id} ==")
try:
info = api.model_info(repo_id)
print("model_info:", info.id)
except Exception as exc:
print("model_info failed:", type(exc).__name__, exc)
try:
path = hf_hub_download(
repo_id=repo_id,
filename="config.json",
)
print("hf_hub_download:", path)
except Exception as exc:
print("hf_hub_download failed:", type(exc).__name__, exc)
try:
path = snapshot_download(
repo_id=repo_id,
allow_patterns=["config.json"],
)
print("snapshot_download:", path)
except Exception as exc:
print("snapshot_download failed:", type(exc).__name__, exc)
try:
config = AutoConfig.from_pretrained(repo_id)
print("AutoConfig:", config.model_type)
except Exception as exc:
print("AutoConfig failed:", type(exc).__name__, exc)
from datasets import load_dataset_builder
for dataset_id in [
"DZER-Studios/<dataset>",
"Vexion-LM/<dataset>",
]:
print(f"\n== {dataset_id} ==")
try:
builder = load_dataset_builder(dataset_id)
print("builder:", builder.info.builder_name)
except Exception as exc:
print("load_dataset_builder failed:", type(exc).__name__, exc)
These checks do not prove every kind of compatibility. Their purpose is to avoid treating one successful browser redirect as proof that all clients and integrations remain compatible.
The official Repository Settings documentation directs users to website@huggingface.co for repository-transfer cases that cannot be completed through the documented UI.
The same address has also been used in public forum discussions involving account and organization naming or ownership issues.
That makes the address plausible, but I could not find:
A follow-up is likely easier to route if it clearly says organization username / namespace, rather than only “organization name” or “username.”
For example:
Hello,
I am an administrator of this Hugging Face organization:
https://huggingface.co/DZER-Studios
I would like to rename the organization username / namespace from:
DZER-Studios
to:
Vexion-LM
I originally contacted website@huggingface.co on June 15, 2026.
In Organization settings → Account, the Organization Username field is:
[editable / read-only / absent / producing this validation error]
Could you please confirm:
1. Whether this organization namespace rename is currently supported.
2. Whether it can be completed by an organization admin through the UI.
3. Whether existing Model, Dataset, and Space URLs will redirect.
4. Whether old repo IDs will remain usable with Git, huggingface_hub,
Transformers, and Datasets.
5. Whether likes, download counts, discussions, pull requests, commits,
Space configuration, and other repository metadata will be preserved.
6. Whether any existing resources require special handling.
Thank you.
A screenshot of the relevant Account setting may also help, provided that private email, billing, token, membership, and security information is removed.
My best non-staff interpretation is:
Account > Org username route existed in at least one documented 2023 case.org.rename separately from profile-setting changes.Therefore, I would not say that organization renaming is unsupported.
I would also not promise that:
The most useful dividing line is the admin view of:
Organization settings → Account → Organization Username
If it is editable, the current UI warning is likely the best available evidence.
If it is read-only even for an admin, the answer is probably internal to HF’s permissions or organization state, and ordinary forum users cannot reliably determine it.
Thanks for the information. I know the reason myself: the account previously had the username “BroSoft.” About six months later, I renamed it “DZER-Studios.” Then I considered changing it again, because the name either didn’t suit me or was already taken. As I later learned, you can only change your username once. After that, if I try to change it again, I just get a 403 error. There’s a chance I simply lost the right to change the name. It’s only granted once. The name is the hardest part. I often type in the name I want to use, but it’s not online, and after I’ve added it to the website, it turns out the company already exists. I have to change it. It’s the same with models: the name “Vexion-LM” itself is still available, but other names like “Vexion” and “vexionic” are already taken. If the model name is still in place and I like it, then the name of the same organization and, so to speak, my own “name.” I still want something unique. But unfortunately, many people are busy with uniqueness, so I have to change it often. Right now, the name “DZER-Studios” seems to fit the model, so I’m less concerned about changing it.