- Product overview
- Images and media
Images and media
You upload the photo your phone took. Zabuno checks it for malware, makes the smaller copies a phone on a slow connection can actually load, and keeps your original untouched so the copies can always be made again.
The photo from the phone is the wrong photo
A picture straight from a phone is several megabytes wide enough to print. Sent to a guest on a crowded restaurant connection, it is a menu that loads after the waiter has already come back.
The usual fixes are worse. Resizing by hand means every photo is a slightly different size. Uploading whatever fits means the guest pays for it, and the guest is the one person who cannot complain to you about it.
One upload, several sizes, one original
Every image is stored twice over: the original exactly as you sent it, and the delivered copies made from it. Because the original is kept, a copy can be rebuilt later without asking you to find the photo again.
What the product cannot do, it refuses out loud. A file it cannot decode, a file that will not scan, a drawing that hides a script - each is rejected with the reason, rather than accepted and quietly broken on the guest's screen.
From your phone to the table
- The file is read, not trusted The first bytes decide what a file really is. A photo renamed to look like something else is caught here, because the extension is never the answer.
- Held apart and scanned The upload waits in quarantine until a malware scan clears it. If the scan cannot run, the file is held rather than let through - the safe answer is the closed one.
- Smaller copies, made once The delivered copies are generated at the widths that slot needs, cropped to its shape, and encoded as WebP where the server supports it. Nothing is ever enlarged past the original.
- Served with a fingerprint Each copy has an address containing a fingerprint of its bytes, so browsers may cache it for a year. Change the image and the address changes; nobody has to clear a cache.
- Attached to a dish, at a version A photo is bound to a menu item at a specific version, and a published menu keeps showing the version it was published with.
What the media library does
- Photos on dishes and a logo on the brand
- A picture for a menu item and a logo for the business. The logo also travels into the printed QR cards, so the table card is yours and not a generic square.
- Alt text is asked for, not optional
- Every upload carries a description. A guest using a screen reader hears what the dish looks like instead of hearing a file name.
- Crop before you upload, and a photo made smaller in the browser
- The picture is cropped and shrunk on your own device before it is sent, so a slow upload from a phone in the restaurant is a short one.
- A photo from an iPhone is handled
- The HEIC format phones save in is converted to JPEG in the browser before it is sent, because the server cannot read HEIC and says so plainly instead of failing.
- Folders, and a filter that follows them
- Two levels of folders to keep starters apart from desserts. There is no third level, because a library nobody can navigate is not tidier.
- Convert an image to another format
- An existing image can be converted to WebP, AVIF or JPEG where the server supports that format. The original is kept and a new version is opened rather than overwritten.
- Versions, and a way back
- Replacing a photo opens a new version. The old one is still there and can be restored, so a bad swap on a busy evening is not permanent.
- "Where is this used?" before it is deleted
- Deleting shows the dishes an image is attached to first. It then goes to the trash, not out of existence, and can be restored.
- Nothing a live menu shows is purged
- The permanent clear-out skips any file a published menu still displays. A guest holding a printed code does not watch a photo disappear.
- A record of who changed what
- Uploads, replacements and deletions are written down with the person and the time.
What you need
| Permission to manage media | Uploading and deleting belong to the media permission. A team member without it can read the menu but cannot change its pictures. |
|---|---|
| A file the product accepts | Photographs as JPEG, PNG, GIF or WebP; logos as SVG; documents as PDF. Anything else is refused at the door with the reason. |
| A file inside the size limits | Twenty-five megabytes for a photograph, two for a logo drawing, forty-five for a document, and no file above forty megapixels. |
| Room inside your plan | Storage, the number of files and the monthly upload count depend on the plan. Running out blocks new uploads only; the menu already published keeps being served. |
| A malware scanner on the server | Scanning is done by a scanner installed alongside the product. Where it is missing, uploads are held rather than waved through. |
What it does not do
- No video There is no video pipeline at all. A video file is recognised by its container and refused, rather than accepted and left unplayable.
- No background removal and no generated pictures Photos are resized, cropped to the slot and re-encoded. They are not retouched, cut out from their background or invented.
- No watermark Images are delivered as they are. Nothing is stamped over them.
- No focal point, no enlarging Where a slot has a fixed shape the crop is taken from the centre; you cannot mark the part that must survive. An image smaller than the target is never blown up.
- No animation A moving image is reduced to a single frame. An animated menu photo is not a supported thing.
- The original keeps its camera data The copies a guest downloads are re-encoded and carry no camera metadata. The original you uploaded is stored exactly as it arrived, location tag and all.
- No search box in the library You can filter by folder and sort by date, name or size. There is no text search across file names.
- No cover picture for a PDF A document is stored and can be read in the panel, but no thumbnail is generated for it. An invented cover would be a picture of nothing.
- No pictures on categories A photograph attaches to a dish or a brand logo. A section heading on the menu does not carry an image.
- Whether the guest sees the photo depends on the plan Uploading, storing, versioning and seeing a photo in the panel work on every plan. Showing it to the guest on the menu is a paid right, and a workspace without it simply shows the dish without a picture — no empty frame and no notice for the guest.
- Files are served by the product, not a delivery network Images come from the same server the menu does. There is no separate content network in front of them.
Questions owners ask
Can I upload the photo straight from my phone?
Yes, including the HEIC files an iPhone saves. It is converted and shrunk in your browser before it is sent, so the upload is short even on the restaurant connection.
Will my guests download a huge file?
No. The guest gets a copy made for the size it is shown at, encoded small, and cached by their browser afterwards.
Can I add a video of the kitchen?
No. There is no video support of any kind, and a video file is refused at upload rather than accepted and left broken.
Can Zabuno remove the background from my photo?
No. Images are resized and cropped, not edited.
What happens if I delete an image that is on the menu?
You are shown where it is used first. It then goes to the trash and can be restored, and the permanent clear-out refuses to touch anything a published menu still shows.
Do I have to write alt text?
Yes, and it is deliberate. It is what a guest using a screen reader hears, and it is a sentence only you can write.
Storage grows with the plan
See how much room each plan gives, and what stays open without one.
See the plans