Treat these as three separate decisions. Removing your involvement from a shared project, changing who can edit a co-owned project, and deleting your whole profile are different actions with different effects on other people's work. An accepted co-owned project appears on multiple owners' profiles, and co-owners can have editing and control rights, while a credit is only an attribution field. Deleting the original uploader's profile can leave a project on co-owner profiles, and unpublishing or deleting a shared project can affect the people associated with it. So the careful sequence is to identify who holds which role, decide what should happen to the work itself, and only then choose the smallest action that matches your goal.
Find public social profile clues with our TraceSeek app.
Separate the three questions before you act
Owners often mix up three intentions: stepping back from a shared project, controlling how it is edited, and leaving Behance entirely. They are not the same operation. Before any change, write down which outcome you actually want, because the smallest action is often enough. If your goal is to stop maintaining a project, you may not need to touch your profile at all. If your goal is to leave the platform, you still need to think about what happens to projects that other people also helped make. [Behance Help: co-owning versus crediting]
Understand what co-ownership and credit actually mean
An accepted co-owned project appears on the profiles of each owner and gives co-owners editing and control rights, while a credit is a separate attribution field. This matters when you are the original uploader deciding whether to remove people or step away. A credit records contribution but does not, by itself, describe editing power. A co-owner is a partner in the project, not just a name attached to it. Reading the roles carefully protects collaborators from losing access they reasonably expected to keep. [Behance Help: co-owning versus crediting]
What deletion does, and what it does not promise
Deleting the original uploader's profile can leave a project visible on co-owner profiles, so profile deletion is not a guaranteed way to make a shared project disappear everywhere. Unpublishing or deleting a shared project does affect associated collaborators, which is why owners should review roles before removal. Do not promise that every public copy will vanish; plan for the realistic result rather than the ideal one. [Behance Help: co-owning versus crediting]
- Identify who is original uploader, who is co-owner, and who is credited before changing anything.
- Decide whether the project should remain public, change status, or end, and tell the affected people first.
| observation | limit | next step |
|---|---|---|
| A project is co-owned by two people | Both co-owners can hold editing and control rights | Compare roles before removing or unpublishing anything |
| The original uploader deletes their profile | The project may still appear on co-owner profiles | Decide with co-owners what should happen to the work |
| A shared project is unpublished or deleted | Associated collaborators are affected | Review roles and give collaborators notice before acting |
Protect a collaborator's legitimate work
Removal is not only a technical step; it has consequences for people who contributed. If a collaborator's work is legitimately part of the project, the considerate approach is to agree on the outcome before changing roles or status. Ask whether they want the project to continue on their profile, whether their credit should remain, and what they will tell viewers. Keep the conversation factual: describe what each control does rather than asserting what the platform will do in every case. If a control or page is unavailable, record that it was unavailable and stop at the access boundary instead of guessing.
- Send a short written message describing the intended change and its likely effect.
- Ask the collaborator to confirm what they want to keep on their own profile.
- Wait for a reply before removing editors or changing project status.
A clearly hypothetical worked example
Suppose, hypothetically, that an owner wants to step back from a co-owned project without disturbing a collaborator's portfolio. They could first confirm who is co-owner and who is credited, then ask the collaborator whether the project should remain public under their care. If the collaborator agrees to continue, the owner might leave the work in place rather than unpublish it. If the collaborator prefers to end it, both would understand that unpublishing or deleting affects associated collaborators. This is only a planning example; confirm the current controls in the official help for your account. [Behance Help: co-owning versus crediting]
Your stopping rule
Set a stopping rule before you start. If the documented control you need is not visible, or the project you are permitted to change is unavailable, record it as unavailable and stop at the access boundary. Use the official current help for your own account rather than trying alternative routes or inspecting anyone else's account. Keep checks to settings you own or are authorized to review. These are observations with limits, not conclusions about other people.
- Log the date, the control you looked for, and whether it was available.
- Stop if access requires someone else's credentials or a workaround.
- Treat results beyond your own account as a limit, not a task to chase.
A couple more questions
If I delete my profile, does the shared project disappear?
Not necessarily. Deleting the original uploader's profile can leave a project on co-owner profiles, so do not assume profile deletion removes the work everywhere.
Does unpublishing a shared project affect my collaborators?
Yes, per the documented guidance. Unpublishing or deleting a shared project affects associated collaborators, so review roles and discuss the outcome before acting.
What is the difference between a co-owner and a credit?
An accepted co-owned project appears on multiple owners' profiles and gives co-owners editing and control rights, while a credit is a separate attribution field.
Sources & editorial notes
Official references checked on October 23, 2026. Checklists, comparison tables and example wording are DateClues editorial tools, not official tests or validated risk scores.
General information. No guide or tool can certify a person’s identity, intentions or safety. Read our editorial standards.