An announcement with a room map makes the distinction concrete. The author can see the map immediately, yet another reader still needs an address that their browser can load after the editing session ends.
Check the image address in the current HTML
With an initialized Froala instance named editor, read its HTML using the documented method:
const html = editor.html.get();
console.log(html);
The Froala methods reference documents html.get(). Inspect the image's src in the returned string. A blob: address refers to browser-managed data, not a durable uploaded file on your server. An https: address still needs checking: it may be temporary, inaccessible to the intended reader, or point to the wrong image.
Compare the HTML at two points: immediately after insertion and in the actual save request. If the editor's latest HTML contains the intended image but the request does not, trace the application's save handler before changing upload settings.
Configure an endpoint that actually exists
In a page where Froala and its image plugin are already loaded, this configuration points at an illustrative application endpoint:
const editor = new FroalaEditor('#notice-editor', {
imageUploadURL: '/api/notice-images',
imageUploadParam: 'file',
imageUploadMethod: 'POST',
imageMaxSize: 3 * 1024 * 1024,
imageAllowedTypes: ['jpeg', 'jpg', 'png']
});
The endpoint and three-megabyte limit are choices for this example. The configuration does not implement a server or grant anyone permission to upload. Froala documents these image options; choose values that agree with your application's own rules.
On the server, authenticate the request as appropriate, enforce file size and permitted content, choose a storage location, and return the response expected by the editor. Keep those rules on the server even when the browser has matching controls.
The documented success response uses a link property:
{"link":"https://example.com/media/room-map-07.png"}
That is a fictional URL showing the response shape. Your endpoint must return the real stored image address. Returning an HTML login page, a different property name, or malformed JSON leaves the editor without the expected result.
Trace upload and document save separately
Use the browser's Network panel in your running application to follow the map:
- Insert a permitted image and locate the upload request.
- Inspect the actual response body and its returned
link. - Confirm that the editor inserts the returned address into the document.
- Save the announcement through the application's normal route.
- Reopen the saved announcement and load it with the permissions of its intended reader.
These steps distinguish “the file uploaded” from “the announcement stored a reference to it.” A successful upload alone cannot prove the document save succeeded. Likewise, a successful document response cannot prove the image remains accessible.
Froala exposes image.error and upload lifecycle events for reporting failures. Use a visible error message that explains what the author can retry; do not replace a failed upload with an apparently successful save state. The upload documentation describes the response and failure stages.
Finish at the reader's copy
For the room-map example, reopen the announcement, confirm the correct map appears, and check its legibility at the width readers use. If an upload succeeds but that view is blank, inspect the image request's status and access conditions instead of reformatting the paragraph around it.
The Radzen editor guide describes a different component's image pathway. Its binding and upload properties do not transfer to Froala. Keep the saved HTML and the durable image response together when diagnosing this integration, then verify the actual reader view after the editor has been closed.