02 / PRIVATE SHARING
Share selected projects, with a defined access window.
A hosted project does not have to be public. In 6HL, the creator account manages files while visitors enter an access code. Treat the code as a shared access mechanism: it controls what can be opened, but does not establish the identity of the person using it.
Select the projects and the expiry date
New projects are private by default. In the workspace, create an access grant, select the projects it should include and set its validity period. A grant can cover one project or several. Keep the selection narrow when sharing a client proposal or a single review deliverable.
Send the visitor entrance URL and its code. Visitors can also choose View projects on the homepage and enter their access code, including an existing four-letter code. They do not need a creator account or a Google login. They can only open projects included in the grant; knowing a random project path does not grant access. Newly uploaded projects are not silently added to an existing grant.
The six-letter code is reusable and case-sensitive
New access codes consist of six random uppercase or lowercase letters. Case matters: aBzQmR and AbzqMr are different inputs. An active code can be used repeatedly until it expires or is revoked. Creators can continue viewing and copying it while it remains active; it is not a one-time reveal. Existing four-letter and older codes remain valid and work directly at the homepage visitor entrance as well as their original creator space.
The code is deliberately short for convenient sharing. Do not describe it as a strong password or use it as a substitute for identity verification. Anyone who receives the code may pass it on. Share it only with the intended recipients and choose a validity window that fits the task.
- Copy the code exactly, preserving letter case.
- Send the visitor entrance, not your creator workspace URL.
- Check the project selection and expiry before sending.
Replace the content without rebuilding the grant
Updating an existing project overwrites its files while keeping the project address, access code and grant state. This works well for iterative prototypes: reviewers return to the same link to see the next revision. Their browsers may still need a refresh to show the new page.
Because the grant points to a project rather than a frozen copy, a revision can change what existing recipients see. Review the new file for confidential material before replacing it. If two audiences should see different versions, create separate projects and separate grants instead.
Expiry and revocation limit future access
You can adjust the grant’s project selection and expiry while it is active, or revoke it when sharing should stop. Expiry and revocation block subsequent access. They cannot erase a downloaded file, a screenshot, or content already loaded in another person’s browser.
For a review cycle, create the grant after checking the hosted page, send it to the intended reviewer, update the same project as needed, and revoke access when the review ends. For highly sensitive information, first decide whether sharing a downloadable browser document is appropriate at all. Access codes are practical controls, not a promise that copies cannot exist.