FREE: Web UI (HTML/CSS/JS Interface)

Alright so there’s more updates to share. First is that the website is FINALLY being overhauled with descriptions, images, download links, and eventually more detailed documentation as previously mentioned. You should be able to subscribe to our mailing list in the next few days:

Also since UE4 is winding down and 4.27 may very well be the last version, perhaps it is time to actually fork the CEF which has been inaccessible this entire time due to being placed in a “private” folder by the engine developers. This means there would be no more C++ snippets in the documentation because custom cursors would be fixed automatically. Plus we could implement a toggle for WebGL and everyone that isn’t compiling from source wouldn’t have to suffer any longer with the 4.24+ performance issues.

So all plugins will be updated this weekend with new versions. I know I said last time it would only be a few days but we ended up making a lot of progress on the JSON assets plugin instead. I’m going to make another post about that in a few minutes once I collect the screenshots.

As mentioned a new plugin is in the works which allows for JSON assets. Since the JSON library is a required part of the WebUI plugin and all of you already have it, I’m going to share the progress made so far.

However this functionality also strays away from the concept of web-based user interfaces and instead focuses on raw data. Therefore I’ll most likely make a new thread for the JSON assets plugin in order to keep the discussions separated. But until the plugin is actually finished and available for download there’s no point in making a thread just yet…

The entire concept is based around that of materials vs material instances. So just like how you create a material, and it has parameters, and then a material instance overrides the default values of those parameters; we’ve implemented a powerful data organization scheme that follows this same concept. You start by creating a new asset under blueprints of type STRUCTURE INSTANCE.


It will then ask you what structure you would like to create an instance of (similar to how the Data Table asset does). These can be both blueprint-created structures and C++ structures.


You can now open this asset and it will look just like the “default values” section of the structure editor.


It also dynamically updates when you make changes to the parent structure…


Then you can create a variable of type “structure instance” in your blueprints. It can reference the JSON asset directly and then operate on it as either raw JSON or an organized structure.


Plus a great optimization is that this data only calls the parse/stringify functions once during loading and saving of the asset. That means you can reuse a piece of data over and over in different blueprints without needing to constantly instantiate the data.

It also means you don’t have to use blueprints to actually store default values or game settings and can instead move these out into separate “structure instance” assets.

Finally the best part is that these assets can be saved as either .UASSET format or as raw .UTXT format instead…


There’s some other annoying UE4 data that surrounds the custom JSON but it doesn’t take up that much space and most of it is located below your data anyway.


But this is a significant piece of functionality for anyone that uses source control. Right now with everything being binary .UASSET files it can become quickly annoying when needing to constantly upload entirely new files to source control, even if you only changed one small piece of information such as a default value.

Now instead you can feasibly utilize .UTXT files in the course of your everday development and simplify your assets in source control by properly separating text vs binary data. It’s as easy as right clicking and changing the asset type…


So again this is just a preview of the JSON assets plugin and what is to come. I will be making a new thread for the JSON assets plugin once it is available for download.

The WebUI, JSON, and HTTP plugins have all been updated as of 4/26/2021 for engine versions 4.23-4.26 on GitHub. That’s because we actually like, you know, go back to previous versions and update things…unlike the incompetent/lazy engine developers that would never even consider implementing important bug fixes into past versions. Imagine if they actually cared and released 4.23.2 after 4.24 came out? But alas, they have no intention of giving you a “stable” engine build of any kind, hell they can’t even fix extremely game breaking bugs after 4-5 years. Click here for game breaking forward rendering bug that was introduced in 4.15 and has yet to be fixed, so we just hack it out of our source code by completely disabling Alpha2Coverage altogether; they literally couldn’t care any less about VR or MSAA.

Here are the update notes:

  • webui now has forked engine browser to eliminate performance issues
    • fixed performance for 4.24+ without code changes
    • fixed custom mouse cursors without code changes
  • convert structs to json and json to structs
  • parse relaxed json with comments and trailing commas
  • subscribe to mailing list for updates
  • json assets plugin coming soon (check previous post for details)

Here are the download links:

WebUI: 4.26 - 4.25 - 4.24 - 4.23
JsonLibrary: 4.26 - 4.25 - 4.24 - 4.23
HttpLibrary: 4.26 - 4.25 - 4.24 - 4.23

perhaps it is time to actually fork the CEF which has been inaccessible this entire time

Would this mean the browser could be updated to the latest Chromium version?

Yes technically, let me explain…

So basically this update forked the source code that is in your game. That means when you compile a shipping build of say YourGame.exe it has code in there that knows how to launch the CEF. That code does all kinds of things, such as setting the desired FPS, working with the mouse, or applying command line parameters to the CEF (such as enabling/disabling WebGL).

Because this code was all stashed away in a “private” folder of the engine code, it was completely inaccessible and could not be overridden by any plugin code. This code has now been forked, and we can change it as we please.

However this probably changed nothing in terms of updating the CEF itself. Once your game executable is running (for instance YourGame.exe) it launches a subprocess called UnrealCefSubprocess.exe for each individual browser instance. This is the CEF itself, and would be the specific CEF version installed into the engine. It is a completely separate project in the engine and isn’t even in the “runtime” folder but rather the “programs” folder instead.

Does forking the source code from the “runtime” folder help with that? Sure, but that isn’t really the hard part of updating the CEF. As you can see, doing the “runtime” fork wasn’t that big of a deal, it was mostly just a lot of renaming. Doing a “programs” fork though of the UnrealCefSubprocess project would be a lot of work. And compiling the latest version of the CEF itself is a complete NIGHTMARE…

So again doing a “runtime” fork was easy, but we never did it because it wasn’t necessary until they forced WebGL on everyone. Moreover forking such a large piece of source code is BAD PROGRAMMING for the long term. By leveraging the existing browser classes of the engine, the WebUI plugin was always very lightweight and was extremely easy to update across engine versions. Now for instance when reverse updating the fork to 4.24 from 4.25/4.26 where the entire engine migrated from UProperty to FProperty, that fork was now completely incompatible and had to be updated.

If we had done this years ago it would have been a huge PITA to update the plugin for each new release of the engine whenever anything significant was changed, and would have made updates take days or even weeks rather than a matter of hours after new engine releases. This was not something we wanted to do every single engine version. But since the engine is winding down and 4.27 is most likely the last version, it was a lot easier now to compare/contrast the differences and just get it all done at once.

Now with all that being said, we never planned on forking the CEF (even just the “runtime” part iself) especially because the long term plan was to always migrate from the CEF to WebKit. That would completely eliminate the browser subprocess executable and instead would be a WebKit DLL that would be included in your existing game executable. That means the web interface would be ticking/rendering on each game tick, thereby having the same FPS as your game. This is the ultimate end goal, including full console support.

So we don’t really have any plans to update the CEF since it already comes with the engine and supports everything out of the box we’re looking for. You’ve got modern HTML5 and CSS3 along with a decently recent EMCAScript version.

What exactly is it that you’re looking for in a newer CEF version? And are you aware that the CEF is literally bigger than UE4 and takes 3X as long to compile? It’s really not worth the effort unless there’s something extremely necessary…

1 Like

It’s been a while since I’ve worked on my UI but from I believe there were some things related to web components/shadow DOM that hadn’t been implemented in the UE browser’s CEF version yet. I think constructible stylesheets are also relatively recent? Nothing essential, anyways - I didn’t realize what a pain it would be to upgrade.

Thanks for the response!

No problem, happy to help. Hopefully we can get some kind of WebKit support implemented sooner rather than later. It’s nice to get a question though that is actually about web technologies or constructive discussion about certain features. I’m always available to explain why a specific decision was made or design path implemented; and to discuss ideas, features, workarounds, whatever. Unfortunately most of the time it’s either just people claiming something doesn’t work when they can’t figure it out, and even worse not putting in any effort to actually address their own problem, but rather just expecting some free video game development on top of their free plugin (just like the guy asking for browser tabs and address bars when the entire point of the plugin is to actually develop a user interface yourself and not have any low-level browser features). But I’m always happy to assist someone that is clearly putting in the effort to solve a problem and needs actual assistance.

Hello I am a beginner in the matter, but is it possible to retrieve the html tags from a URL loaded in the browser?
I know it may sound stupid but hey I still prefer to ask …

No need to worry about being a beginner, we’ve all been there. I appreciate you pointing that out though. I assume by HTML tags you mean the HTML source of the page that is currently loaded? This is technically possible but the functionality for it has not been exposed to blueprints. That’s because it’s not really something within the scope of this plugin. It is not meant for surfing web pages or anything that would involve the need to work with HTML source, as the WebBrowserWidget that comes with the engine is more designed for that.

Are you looking to debug your page while you’re working on your game? You can do this with CTRL+SHIFT+I which is also outlined in the documentation. Otherwise perhaps you can provide more insight into what you’re looking to achieve and why you need that functionality?

I also wanted to post a quick note about the JsonAssets plugin. There has been more progress on UTXT assets. First I took the time to compare some different engine versions, and didn’t realize that a few things were updated in 4.24 for text assets.

However while they completely changed the text format itself in 4.24 and fixed a few random bugs (such as text assets not loading in the content browser unless referenced by a binary asset that’s being loaded) mostly everything else remained the same in terms of everything being completely unfinished and unusable. Plus none of this really matted since the JsonAssets plugin already fixed many of these existing engine issues.

The initial plan was to only work with UTXT asset in-editor and then require these files to be converted to UASSET before cooking your game. This could have been taken a step further by automating the process so it temporarily renames UTXT assets while saving UASSET versions for cooking and then resetting everything afterwards. But this is not a good design plan and wasn’t really the long term goal.

Now the thing is UTXT files are not supported by cooked builds, and quite frankly that is probably a really good design decision anyway. So if we’re not going to allow UTXT assets to even be cooked, there was only one clear solution which I’m happy to report we got working…

This is of course still being able to utilize UTXT assets, but then having them cooked as UASSET files directly. That means there’s no changes to your content directory itself, and everything takes place during the cooking process instead.

So now with this new update we’ll be able to work with raw text-based UTXT assets using JSON, then package for ANY platform, and have all this data cooked as binary UASSET files. Unfortunately this did delay the actual release of the JsonAssets plugin as some of this new functionality is being tested really quick. But it seemed like the right decision to just put everything together the right way like this instead of having something half-finished (kinda like the engine devs) with weird workarounds for cooking.

I’m here to thanks your works! This plugin is great.

But there is a problem on the latest version. When i use it as the project plugin to build my project, the engine will indicate the lnk error 2005 with the original WebBroswer.cpp. I believe it’s related to the WebBrowserUI but i have no idea how to fix this. It would be nice to hear your advice!

I am currently looking to retrieve the source of an image from a URL without having to do it manually. (Passing through http requests so that depending on the profile, it always retrieves the class of the img file)
The problem is that on some sites where javascript is running, I don’t have access to the dynamically generated HTML code when I make an HTTP request.
That’s why I thought I would go through your plugin because it simulates a browser and I wanted to retrieve the data with this one

Thanks for taking the time to report this and for providing a linker error code. However we’re already aware of this issue and are planning to release an update either later today or tomorrow the latest. You can track the progress here:

Well that doesn’t sound like something a beginner would be doing. I mean when you asked your question you were extremely vague and said “can I get the HTML tags of the page?” and then left it at that. Now all of a sudden you have quite the vocabulary in order to properly explain your problem, such as “looking to get the dynamically generated HTML code when I make an HTTP request” which demonstrates you know exactly what you’re talking about.

Perhaps you should have said that in the first place then? But if you are a beginner then that’s probably why you’re not familiar with the innerHTML property in JavaScript (except jQuery has a simple wrapper too). So even though this has nothing to do with web-based user interfaces for video games, I guess I’ll answer your question since it seems applicable, which is that this is probably what you’re looking for…

ue4('myeventname', document.body.innerHTML);

or with jQuery…

ue4('myeventname', $('body').html());

You should obviously be able to apply this to any HTML tag that you’d like to query. I’m not going to sit here and explain to you how jQuery works, but I’ll at least give you raw JavaScript just in case:


And that will work for any HTML ID. If you don’t even know what those are, then same answer, I’m not going to sit here and explain all that to you. Go read, learn, ect.

1 Like

This issue should now be resolved. Please download the latest update and let us know if you still experience any linker errors. Thanks again for taking the time to report this issue!

Oh I also forgot to mention that the JsonAssets plugin has finally been released! Here are the download links:

JsonAssets: 4.26 - 4.25 - 4.24 - 4.23

You can find the corresponding thread for it here:

Hey guys!

I’m not super technical, but I know my way around blueprints. Tackling a new challenge these days, trying to make an iOS app.

@spidershift thanks for making this amazing plugin! I am still not sure why UE4 doesn’t have this functionality built-in, the UMG system is so cumbersome to scale, at least from BP side.

I am working on windows, so trying to package the project for iOS from windows.
I am trying the 4.26 version (I couldn’t manage to package even an empty project for 4.23 for iOS).

I can package and run it for windows without a problem.

I can package it for iOS if I put the plugin in the project directory, but when I run it on the iPad, it opens up and instantly closes, I haven’t looked into if there is a crash log or something, or where to find it on iPad. I tried packaging your example project, or even an empty project, with no logic added to the project, just the plugin activated. Still shows the same behavior.

If I try to put the plugin in the “Plugins/Runtime”, then I get an error when trying to launch the project for iOS, I get this error:

LogPlayLevel: Setting up ProjectParams for D:\Temp\WEB_UI_Sample\WebInterface.uproject
LogPlayLevel: WebInterface.uproject requires a temporary target.cs to be generated (WebUI plugin is enabled)
LogPlayLevel: ********** STAGE COMMAND STARTED **********
LogPlayLevel: Error: ERROR: Stage Failed. Missing receipt ‘D:\Temp\WEB_UI_Sample\Binaries\IOS\’. Check that this target has been built.
LogPlayLevel: (see C:\Users\Sergiu\AppData\Roaming\Unreal Engine\AutomationTool\Logs\D+EpicGames+UE_4.26\Log.txt for full exception trace)
LogPlayLevel: AutomationTool exiting with ExitCode=103 (Error_MissingExecutable)
LogPlayLevel: Completed Launch On Stage: Build Task, Time: 1.003088
LogPlayLevel: Completed Launch On Stage: Deploy Task, Time: 0.000051
PackagingResults: Error: Launch failed! Missing UE4Game binary.
You may have to build the UE4 project with your IDE. Alternatively, build using UnrealBuildTool with the commandline:

If I try to package it, I get this error:

UATHelper: Packaging (iOS): ERROR: Remote compiling requires a server name. Use the editor (Project Settings > IOS) to set up your remote compilation settings.
PackagingResults: Error: Remote compiling requires a server name. Use the editor (Project Settings > IOS) to set up your remote compilation settings.
UATHelper: Packaging (iOS): Took 0.3625059s to run UnrealBuildTool.exe, ExitCode=6
UATHelper: Packaging (iOS): UnrealBuildTool failed. See log for more details. (C:\Users\Sergiu\AppData\Roaming\Unreal Engine\AutomationTool\Logs\D+EpicGames+UE_4.26\UBT-WebInterface-IOS-Development.txt)
UATHelper: Packaging (iOS): AutomationTool exiting with ExitCode=6 (6)
UATHelper: Packaging (iOS): BUILD FAILED
PackagingResults: Error: Unknown Error

Please not I can package for iOS and run on iPad without any problems if the plugin is not enabled.

Did anyone try to run this on an iPad on 4.26?

Thanks so much!


PS: the new forum is horrible.

Thank you for actually taking the time to write up a detailed description of your problem and for providing a log of your issue. You’d be surprised how difficult it is for some people to follow this basic concept when they run into issues with software.

Now I don’t know anything about remote compiling for iOS. We did compile for Mac a few years ago to test how well it worked for UE4 (which of course was not well at all) and compiled that directly on a remote Mac server but never used it long enough to setup remote compiling. However if you’re saying everything works completely fine without the plugin then at least we don’t have to worry about that being an issue.

So let’s clear up a few things first before we waste our time debugging something we don’t have to. Start by heading over to GitHub and download the latest ZIP and try compiling again. We released an update that fixed a few linker errors but there were 2 lines with a spelling error in the iOS files. Someone brought this to our attention last night and we fixed the CPP file immediately. Now since we don’t compile for iOS this didn’t require new builds of the plugin, but the code was updated.

Therefore you should try downloading the latest before we put effort into this. You can find the issue regarding this problem here:

Otherwise if it still doesn’t remote compile after that then we’ll look into this. However I would prefer you post your issue on GitHub then as we like to use that for actual errors/crashes so we can keep them organized per issue. But please don’t think of that as an open invitation to just post your problems on GitHub whenever you run into an issue or have a question. The issues section has a very specific function so use it appropriately.

But yes, test the latest ZIP first and we’ll go from there.

Also, if it still doesn’t remote compile, please try and go get an error log from your remote machine. You did take the time to share your log which is great, but unfortunately there isn’t any useful information there, as all it says is that the remote compile failed. We need to know what actually failed so that requires getting the compiler log itself. It does say something about not connecting to the server, but again, if as you said it remote compiles without the plugin, I don’t know why it would say something like that as the reason for the failure.

hi Spidershift!

Thanks for your reply!

I’m not actually remote compiling, my project is blueprint only, so I’m compiling using the built in compiler (I think, not sure how that works on building iOS projects from windows).

But I am getting a “remote compiler” error when building the project with the plugin in the engine installation directory. I’m not really sure if that’s expected behavoir and I have to use a remote compiler if using 3rd party plugins. Would that be the case?

If I compile with the plugin in the project folder, I don’t get any errors, but when I run the app on my ipad, it opens, and then closes after the UE4 splash screen.

I think I have the latest version, but I will double check and get back to you!

Thanks again!

You are correct in that you did not say you are remote compiling. That is my bad for making that assumption. But no that’s not how this works. It outlines everything right here for you:

As it says, and as I will explain in more detail, you can only make iOS projects on Windows if they are BLUEPRINT ONLY. Since you have a custom plugin with custom C++ code, that requires actually making a full build.

Now if we had access to a Mac server to make plugin builds, we could have provided precompiled binaries for the Mac/iOS platforms (just like we did for Linux/Android) which would have allowed you to do exactly what you are trying to do. The problem is you CANNOT compile Apple software except on Apple computers, period. On the other hand Microsoft lets you compile their software on ANY platform, which is why Apple is such a ridiculous company and just further alienates anyone with actual technical expertise. It is 100% an OS for computer illiterates or technology challenged “artists” doing audio mixing or photoshopping or whatever. Therefore unless we take the time to either buy a Mac computer (never gonna happen) or rent a Mac server for the insane cost of $60/month for the most basic hardware, we have no way to compile these plugins for Apple software. It doesn’t mean that they aren’t supported, but just that we have no way to build them ourselves for you without paying for something we don’t want or need anytime soon.

So what happens is, UE4 provides precompiled binaries of the plain jane engine such as UE4Game.exe for Windows or UE4Game (with no extension) for iOS. That means when you package from the editor, the ONLY thing it is doing is COOKING and PACKAGING your game. There is zero compiling taking place on your computer for Apple sofware, at all. So what’s happening is, you’re deploying your project to your iPad, but the UE4Game application is completely missing the code for the plugin and crashing since you neither have precompiled binaries for it nor have you setup remote compiling to make them yourself.

This is why there’s a remote compiling feature built into the engine. That means instead of having to take the time to download your project to a Mac and build everything there (which is what we did when we were testing it) you can actually just setup an SSH key to remotely connect, so you can still do a full build for ALL platforms on your Windows machine, but the remote Mac will do its thing just for Mac/iOS builds.

If you want to do this, it’s pretty easy to setup, we used a service called MacStadium to do it previously, but again it’s like $60 just to rent the server to do that. There’s instructions at the end of the WebUI documentation on how to compile the plugin on Windows, and you can follow the previous link for setting up remote compiling. You would have to edit your UPLUGIN file to remove the Linux/Android platforms but leave the iOS one (and maybe even the Mac one too). Keep in mind you would have to do this for the JsonLibrary as well since it’s a required plugin for the WebUI plugin.

If you end up doing this and want to be really nice, you can run the full compile and then send us the /Binaries and /Intermediate folders for both the JsonLibrary and WebUI so we can include them in the 4.26 ZIP files for others that might want to package blueprint-only projects for Mac/iOS so they don’t have to go through the trouble you did. But that doesn’t really help in the long term because not only does that exclude everyone on previous versions of UE4 which still won’t have these precompiled binaries; the moment we make an update or bug fix we would have to throw the binaries away anyway.

Now with all that being said, we don’t really plan to update the WebUI any time soon since it already has all the features we’ve been planning the past few years. Our focus is now more on building out other plugins. So if you want to do that, we have no problem updating the 4.26 ZIP files for ALL platforms.

Otherwise your only remaining option is to contact the guy that posted the original issue on GitHub that I linked to you in my previous post. They have a full package of the WebUI for iOS already since they were the one that brought the compiler issue to our attention and confirmed that everything was fixed for iOS.