Synthetic faces are portraits of people who never existed. The image is generated, not photographed, and no consent was collected because there is nobody to ask. That single property decides where the image can go.
The face generator API returns one such portrait per call: JPEG, PNG, base64 or JSON, with an optional square size and JPEG quality.
curl -s "https://api2.globus.studio/v2/facefake?size=512" --output face.jpg
What you get back
The default response is a JPEG. format=png returns a PNG; format=base64 and format=json return a data URI inside a JSON object, which is easier for clients that cannot handle binary responses.
size scales the cropped face to a square. quality sets the JPEG quality from 0 to 100, with 85 as the default. Each call produces a different person, so keep the file you used if the mockup has to stay stable.
Four honest uses
Synthetic faces fit where nobody is expected to believe the person exists:
- filling an avatar slot while a design is in progress;
- building a test fixture for a user list or a customer dashboard;
- illustrating an article about privacy, synthetic media or datasets;
- populating a demo that ships to a client without any personal data.
The list is short on purpose. Every item has the same shape: the image is a placeholder, and the surrounding text says so.
Three uses that backfire
The first is a testimonial. A quote next to a generated portrait claims a person said something, and when the portrait is exposed as synthetic, the quote stops being read as well.
The second is a team page. Invented colleagues on a landing page are easy to spot from a reverse image search and expensive to explain to a client.
The third is identity. Synthetic faces do not belong in documents, verification flows or anything that decides who someone is. The generator does not accept a reference photo, and pushing it toward a named person turns a design tool into a deepfake tool.
Label the image
Alt text and a caption cost nothing and prevent an argument later. “Portrait placeholder” is honest. “Photo of Anna, our accountant” is a claim the image cannot support.
On a page, set width and height so the layout does not jump, and keep the file local: a portrait does not need a new request per page view. If a dataset of synthetic faces is published, label it as synthetic in the metadata too.
Failure modes to handle
The portrait comes from an external provider, so the endpoint fails when that provider changes or blocks the server. Failed to fetch image means no image arrived; Failed to process image means the response was not a picture. Both are temporary, and both should be retried later rather than treated as a broken key.
Generation is heavier than a lookup, so the route is rate limited and a 429 carries Retry-After. In a bulk script, generate what you need once, store it, and reuse the files.
Synthetic faces and the law
Disclosure rules differ by country and by platform. The safe default is the same everywhere: say that the image is generated, and never place it next to a claim about a real person. A short caption is cheaper than the cleanup.
Related reading
For a plain rectangle with exact dimensions, the placeholder image guide is lighter and always available. For a link or a short string as a scannable image, see generating QR codes.
Build a small library you can defend
A mockup rarely needs a hundred faces. Generate a handful of synthetic faces, save them with a note that says where they came from and that the person does not exist, and reuse them across demos. A folder of five labelled portraits is easier to audit than a cache of five hundred, and the note answers the question a client will ask. When an image leaves the project, the note travels with it: a caption, a field in the media library or a line in the README. That record costs a minute and prevents the argument that starts when a synthetic portrait is mistaken for a real colleague.
Further reading: Content Authenticity Initiative on labelling synthetic media.